Krzysztof Gogolewski authored 1 year ago and Marge Bot committed 1 year ago

Fixes #23930

Matthew Pickering authored 2 years ago and Marge Bot committed 1 year ago

Tracking ticket: #23059

This runs compile_and_run tests with optimised code with bytecode
interpreter

Changed submodules: hpc, process

Co-authored-by: Torsten Schmits <git@tryp.io>

Krzysztof Gogolewski authored 1 year ago and Marge Bot committed 1 year ago

The tests were originally skipped because ghci used not to support
unboxed tuples/sums.

Torsten Schmits authored 2 years ago and Marge Bot committed 1 year ago

Tracking ticket: #20117

MR: !10183

This converts uses of `mkTcRnUnknownMessage` to newly added constructors
of `TcRnMessage`.

jeffrey young authored 2 years ago and Marge Bot committed 2 years ago

This MR runs the testsuite for the JS backend. Note that this is a
temporary solution until !9515 is merged.

Key point: The CI runs hadrian on the built cross compiler _but not_ on
the bindist.

Other Highlights:

 - stm submodule gets a bump to mark tests as broken
 - several tests are marked as broken or are fixed by adding more
 - conditions to their test runner instance.

List of working commit messages:

CI: test cross target _and_ emulator

CI: JS: Try run testsuite with hadrian

JS.CI: cleanup and simplify hadrian invocation

use single bracket, print info

JS CI: remove call to test_compiler from hadrian

don't build haddock

JS: mark more tests as broken

Tracked in #22576

JS testsuite: don't skip sum_mod test

Its expected to fail, yet we skipped it which automatically makes it
succeed leading to an unexpected success,

JS testsuite: don't mark T12035j as skip

leads to an unexpected pass

JS testsuite: remove broken on T14075

leads to unexpected pass

JS testsuite: mark more tests as broken

JS testsuite: mark T11760 in base as broken

JS testsuite: mark ManyUnbSums broken

submodules: bump process and hpc for JS tests

Both submodules has needed tests skipped or marked broken for th JS
backend. This commit now adds these changes to GHC.

See:

HPC: hpc/hpc!21

Process: https://github.com/haskell/process/pull/268

remove js_broken on now passing tests

separate wasm and js backend ci

test: T11760: add threaded, non-moving only_ways

test: T10296a add req_c

T13894: skip for JS backend

tests: jspace, T22333: mark as js_broken(22573)

test: T22513i mark as req_th

stm submodule: mark stm055, T16707 broken for JS

tests: js_broken(22374) on unpack_sums_6, T12010

dont run diff on JS CI, cleanup

fixup: More CI cleanup

fix: align text to master

fix: align exceptions submodule to master

CI: Bump DOCKER_REV

Bump to ci-images commit that has a deb11 build with node. Required for
!9552

testsuite: mark T22669 as js_skip

See #22669

This test tests that .o-boot files aren't created when run in using the
interpreter backend. Thus this is not relevant for the JS backend.

testsuite: mark T22671 as broken on JS

See #22835

base.testsuite: mark Chan002 fragile for JS

see #22836

revert: submodule process bump

bump stm submodule

New hash includes skips for the JS backend.

testsuite: mark RnPatternSynonymFail broken on JS

Requires TH:
 - see !9779
 - and #22261

compiler: GHC.hs ifdef import Utils.Panic.Plain

Krzysztof Gogolewski authored 2 years ago and Marge Bot committed 2 years ago

Fixes #11270

Andreas Klebinger authored 2 years ago and Marge Bot committed 2 years ago

Unboxed sums might store a Int8# value as Int64#. This patch
makes sure we keep track of the actual value type.

See Note [Casting slot arguments] for the details.

Add JS backend adapted from the GHCJS project by Luite Stegeman.

Some features haven't been ported or implemented yet. Tests for these
features have been disabled with an associated gitlab ticket.

Bump array submodule

Work funded by IOG.

Co-authored-by: Jeffrey Young <jeffrey.young@iohk.io>
Co-authored-by: Luite Stegeman <stegeman@gmail.com>
Co-authored-by: Josh Meredith <joshmeredith2008@gmail.com>

Ben Gamari authored 2 years ago and Marge Bot committed 2 years ago

`grep -q` closes stdin as soon as it finds the pattern it is looking
for, resulting in #22484.

Ben Gamari authored 2 years ago and Marge Bot committed 2 years ago

This test is explicitly dependent upon runtime, which is generally not
appropriate given that the testsuite is run in parallel and generally
saturates the CPU.

Vladislav Zavialov authored 2 years ago and Marge Bot committed 2 years ago

Before this patch, GHC unconditionally printed ticks before promoted
data constructors:

	ghci> type T = True  -- unticked (user-written)
	ghci> :kind! T
	T :: Bool
	= 'True              -- ticked (compiler output)

After this patch, GHC prints ticks only when necessary:

	ghci> type F = False    -- unticked (user-written)
	ghci> :kind! F
	F :: Bool
	= False                 -- unticked (compiler output)

	ghci> data False        -- introduce ambiguity
	ghci> :kind! F
	F :: Bool
	= 'False                -- ticked by necessity (compiler output)

The old behavior can be enabled by -fprint-redundant-promotion-ticks.

Summary of changes:
* Rename PrintUnqualified to NamePprCtx
* Add QueryPromotionTick to it
* Consult the GlobalRdrEnv to decide whether to print a tick (see mkPromTick)
* Introduce -fprint-redundant-promotion-ticks

Co-authored-by: Artyom Kuznetsov <hi@wzrd.ht>

Madeline Haraj authored 4 years ago and Andreas Klebinger committed 2 years ago

This is based on osa's unpack_sums PR from ages past.

The meat of the patch is implemented in dataConArgUnpackSum
and described in Note [UNPACK for sum types].

Necessary for newer cross-compiling backends (JS, Wasm) that don't
support TH yet.

sheaf authored 2 years ago and Marge Bot committed 2 years ago

As noted in #22297, SIMD vector registers can be used
to store different kinds of values, e.g. xmm1 can be used
both to store integer and floating point values.
The Cmm type system doesn't properly account for this, so
we weaken the Cmm register assignment lint check to only
compare widths when comparing a vector type with its
allocated vector register.

Dai authored 2 years ago and Marge Bot committed 2 years ago

This patch adds the missing `VecRep` case to `primRepSlot` function and
all the necessary machinery to carry this new `VecSlot` through code
generation. This allows programs involving unboxed sums of SIMD vectors
to be written and compiled.

Fixes #22187

sheaf authored 2 years ago and Marge Bot committed 2 years ago

The testsuite output now contains diagnostic codes, so many tests need
to be updated at once.
We decided it was best to keep the diagnostic codes in the testsuite
output, so that contributors don't inadvertently make changes to the
diagnostic codes.

Krzysztof Gogolewski authored 3 years ago and Matthew Pickering committed 2 years ago

Users are supposed to import GHC.Exts rather than GHC.Prim.
Part of #18749.

sheaf authored 3 years ago and Marge Bot committed 3 years ago

The pretty-printing of partially applied unboxed sums was incorrect,
as we incorrectly dropped the first half of the arguments, even
for a partial application such as

  (# | #) @IntRep @DoubleRep Int#

which lead to the nonsensical (# DoubleRep | Int# #).

This patch also allows users to write unboxed sum type constructors
such as

  (# | #) :: TYPE r1 -> TYPE r2 -> TYPE (SumRep '[r1,r2]).

Fixes #20858 and #20859.

Multiple home units allows you to load different packages which may depend on
each other into one GHC session. This will allow both GHCi and HLS to support
multi component projects more naturally.

Public Interface
~~~~~~~~~~~~~~~~

In order to specify multiple units, the -unit @⟨filename⟩ flag
is given multiple times with a response file containing the arguments for each unit.
The response file contains a newline separated list of arguments.

```
ghc -unit @unitLibCore -unit @unitLib
```

where the `unitLibCore` response file contains the normal arguments that cabal would pass to `--make` mode.

```
-this-unit-id lib-core-0.1.0.0
-i
-isrc
LibCore.Utils
LibCore.Types
```

The response file for lib, can specify a dependency on lib-core, so then modules in lib can use modules from lib-core.

```
-this-unit-id lib-0.1.0.0
-package-id lib-core-0.1.0.0
-i
-isrc
Lib.Parse
Lib.Render
```

Then when the compiler starts in --make mode it will compile both units lib and lib-core.

There is also very basic support for multiple home units in GHCi, at the
moment you can start a GHCi session with multiple units but only the
:reload is supported. Most commands in GHCi assume a single home unit,
and so it is additional work to work out how to modify the interface to
support multiple loaded home units.

Options used when working with Multiple Home Units

There are a few extra flags which have been introduced specifically for
working with multiple home units. The flags allow a home unit to pretend
it’s more like an installed package, for example, specifying the package
name, module visibility and reexported modules.

-working-dir ⟨dir⟩

    It is common to assume that a package is compiled in the directory
    where its cabal file resides. Thus, all paths used in the compiler
    are assumed to be relative to this directory. When there are
    multiple home units the compiler is often not operating in the
    standard directory and instead where the cabal.project file is
    located. In this case the -working-dir option can be passed which
    specifies the path from the current directory to the directory the
    unit assumes to be it’s root, normally the directory which contains
    the cabal file.

    When the flag is passed, any relative paths used by the compiler are
    offset by the working directory. Notably this includes -i and
    -I⟨dir⟩ flags.

-this-package-name ⟨name⟩

    This flag papers over the awkward interaction of the PackageImports
    and multiple home units. When using PackageImports you can specify
    the name of the package in an import to disambiguate between modules
    which appear in multiple packages with the same name.

    This flag allows a home unit to be given a package name so that you
    can also disambiguate between multiple home units which provide
    modules with the same name.

-hidden-module ⟨module name⟩

    This flag can be supplied multiple times in order to specify which
    modules in a home unit should not be visible outside of the unit it
    belongs to.

    The main use of this flag is to be able to recreate the difference
    between an exposed and hidden module for installed packages.

-reexported-module ⟨module name⟩

    This flag can be supplied multiple times in order to specify which
    modules are not defined in a unit but should be reexported. The
    effect is that other units will see this module as if it was defined
    in this unit.

    The use of this flag is to be able to replicate the reexported
    modules feature of packages with multiple home units.

Offsetting Paths in Template Haskell splices
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

When using Template Haskell to embed files into your program,
traditionally the paths have been interpreted relative to the directory
where the .cabal file resides. This causes problems for multiple home
units as we are compiling many different libraries at once which have
.cabal files in different directories.

For this purpose we have introduced a way to query the value of the
-working-dir flag to the Template Haskell API. By using this function we
can implement a makeRelativeToProject function which offsets a path
which is relative to the original project root by the value of
-working-dir.

```
import Language.Haskell.TH.Syntax ( makeRelativeToProject )

foo = $(makeRelativeToProject "./relative/path" >>= embedFile)
```

> If you write a relative path in a Template Haskell splice you should use the makeRelativeToProject function so that your library works correctly with multiple home units.

A similar function already exists in the file-embed library. The
function in template-haskell implements this function in a more robust
manner by honouring the -working-dir flag rather than searching the file
system.

Closure Property for Home Units
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

For tools or libraries using the API there is one very important closure
property which must be adhered to:

> Any dependency which is not a home unit must not (transitively) depend
  on a home unit.

For example, if you have three packages p, q and r, then if p depends on
q which depends on r then it is illegal to load both p and r as home
units but not q, because q is a dependency of the home unit p which
depends on another home unit r.

If you are using GHC by the command line then this property is checked,
but if you are using the API then you need to check this property
yourself. If you get it wrong you will probably get some very confusing
errors about overlapping instances.

Limitations of Multiple Home Units
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

There are a few limitations of the initial implementation which will be smoothed out on user demand.

    * Package thinning/renaming syntax is not supported
    * More complicated reexports/renaming are not yet supported.
    * It’s more common to run into existing linker bugs when loading a
      large number of packages in a session (for example #20674, #20689)
    * Backpack is not yet supported when using multiple home units.
    * Dependency chasing can be quite slow with a large number of
      modules and packages.
    * Loading wired-in packages as home units is currently not supported
      (this only really affects GHC developers attempting to load
      template-haskell).
    * Barely any normal GHCi features are supported, it would be good to
      support enough for ghcid to work correctly.

Despite these limitations, the implementation works already for nearly
all packages. It has been testing on large dependency closures,
including the whole of head.hackage which is a total of 4784 modules
from 452 packages.

Internal Changes
~~~~~~~~~~~~~~~~

* The biggest change is that the HomePackageTable is replaced with the
  HomeUnitGraph. The HomeUnitGraph is a map from UnitId to HomeUnitEnv,
  which contains information specific to each home unit.
* The HomeUnitEnv contains:
    - A unit state, each home unit can have different package db flags
    - A set of dynflags, each home unit can have different flags
    - A HomePackageTable
* LinkNode: A new node type is added to the ModuleGraph, this is used to
  place the linking step into the build plan so linking can proceed in
  parralel with other packages being built.
* New invariant: Dependencies of a ModuleGraphNode can be completely
  determined by looking at the value of the node. In order to achieve
  this, downsweep now performs a more complete job of downsweeping and
  then the dependenices are recorded forever in the node rather than
  being computed again from the ModSummary.
* Some transitive module calculations are rewritten to use the
  ModuleGraph which is more efficient.
* There is always an active home unit, which simplifies modifying a lot
  of the existing API code which is unit agnostic (for example, in the
  driver).

The road may be bumpy for a little while after this change but the
basics are well-tested.

One small metric increase, which we accept and also submodule update to
haddock which removes ExtendedModSummary.

Closes #10827

-------------------------
Metric Increase:
    MultiLayerModules
-------------------------

Co-authored-by: Fendor <power.walross@gmail.com>

Ben Gamari authored 3 years ago and Marge Bot committed 3 years ago

Fixes #20541 by making mkTyConApp do more sharing of types.
In particular, replace

* BoxedRep Lifted    ==>  LiftedRep
* BoxedRep Unlifted  ==>  UnliftedRep
* TupleRep '[]       ==>  ZeroBitRep
* TYPE ZeroBitRep    ==>  ZeroBitType

In each case, the thing on the right is a type synonym
for the thing on the left, declared in ghc-prim:GHC.Types.
See Note [Using synonyms to compress types] in GHC.Core.Type.

The synonyms for ZeroBitRep and ZeroBitType are new, but absolutely
in the same spirit as the other ones.   (These synonyms are mainly
for internal use, though the programmer can use them too.)

I also renamed GHC.Core.Ty.Rep.isVoidTy to isZeroBitTy, to be
compatible with the "zero-bit" nomenclature above.  See discussion
on !6806.

There is a tricky wrinkle: see GHC.Core.Types
  Note [Care using synonyms to compress types]

Compiler allocation decreases by up to 0.8%.

Ben Gamari authored 3 years ago and Marge Bot committed 3 years ago

Previously Unarise would happily project lifted and unlifted fields
to lifted slots. This broke horribly in #19645, where a ByteArray# was
passed in a lifted slot and consequently entered. The simplest way to
fix this is what I've done here, distinguishing between lifted and
unlifted slots in unarise.

However, one can imagine more clever solutions, where we coerce the
binder to the correct levity with respect to the sum's tag. I doubt that
this would be worth the effort.

Fixes #19645.

Alan Zimmerman authored 4 years ago and Marge Bot committed 4 years ago

Metric Increase:
       T10370
       parsing001

Updates haddock submodule

This implements the BoxedRep proposal, refactoring the `RuntimeRep`
hierarchy from:

```haskell
data RuntimeRep = LiftedPtrRep | UnliftedPtrRep | ...
```

to

```haskell
data RuntimeRep = BoxedRep Levity | ...
data Levity = Lifted | Unlifted
```

Updates binary, haddock submodules.

Closes #17526.

Metric Increase:
    T12545

This was inadvertently merged.

This reverts commit 6c2eb223.

Andrew Martin authored 4 years ago and Ben Gamari committed 4 years ago

This implements the BoxedRep proposal, refacoring the `RuntimeRep`
hierarchy from:

```haskell
data RuntimeRep = LiftedPtrRep | UnliftedPtrRep | ...
```

to

```haskell
data RuntimeRep = BoxedRep Levity | ...
data Levity = Lifted | Unlifted
```

Closes #17526.

Sebastian Graf authored 4 years ago and Marge Bot committed 4 years ago

Previously, we desugared and coverage checked plain guard trees as
described in Lower Your Guards. That caused (in !3849) quite a bit of
pain when we need to partially recover tree structure of the input
syntax to return covered sets for long-distance information, for
example.

In this refactor, I introduced a guard tree variant for each relevant
source syntax component of a pattern-match (mainly match groups, match,
GRHS, empty case, pattern binding). I made sure to share as much
coverage checking code as possible, so that the syntax-specific checking
functions are just wrappers around the more substantial checking
functions for the LYG primitives (`checkSequence`, `checkGrds`).

The refactoring payed off in clearer code and elimination of all panics
related to assumed guard tree structure and thus fixes #18565.

I also took the liberty to rename and re-arrange the order of functions
and comments in the module, deleted some dead and irrelevant Notes,
wrote some new ones and gave an overview module haddock.

Sylvain Henry authored 4 years ago and Marge Bot committed 4 years ago

- put panic related functions into GHC.Utils.Panic
- put trace related functions using DynFlags in GHC.Driver.Ppr

One step closer making Outputable fully independent of DynFlags.

Bump haddock submodule

Krzysztof Gogolewski authored 4 years ago and Marge Bot committed 4 years ago

There's one backwards compatibility issue: GHC.Prim no longer exports
Void#, we now manually re-export it from GHC.Exts.

Sylvain Henry authored 4 years ago and Marge Bot committed 4 years ago

Update Haddock submodule

Metric Increase:
   haddock.compiler

* SysTools
* Parser
* GHC.Builtin
* GHC.Iface.Recomp
* Settings

Update Haddock submodule

Metric Decrease:
    Naperian
    parsing001

Sylvain Henry authored 5 years ago and Marge Bot committed 5 years ago

Update Haddock submodule

Metric Increase:
   haddock.compiler

Sylvain Henry authored 5 years ago and Marge Bot committed 5 years ago

submodule updates: nofib, haddock

This eliminates most uses of run_command in the testsuite in favor of the more
structured makefile_test.