Bodigrim authored 1 year ago and Marge Bot committed 1 year ago

This requires changing the recomp007 test because now cabal passes
`this-unit-id` to executable components, and that unit-id contains a
hash which includes the ABI of the dependencies. Therefore changing the
dependencies means that -this-unit-id changes and recompilation is
triggered.

The spririt of the test is to test GHC's recompilation logic assuming
that `-this-unit-id` is constant, so we explicitly pass `-ipid` to
`./configure` rather than letting `Cabal` work it out.

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>

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

Fixes #21866

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>

This patch comprises of four different but closely related ideas. The
net result is fixing a large number of open issues with the driver
whilst making it simpler to understand.

1. Use the hash of the source file to determine whether the source file
has changed or not. This makes the recompilation checking more robust to
modern build systems which are liable to copy files around changing
their modification times.

2. Remove the concept of a "stable module", a stable module was one
where the object file was older than the source file, and all transitive
dependencies were also stable. Now we don't rely on the modification
time of the source file, the notion of stability is moot.

3. Fix TH/plugin recompilation after the removal of stable modules. The
TH recompilation check used to rely on stable modules. Now there is a
uniform and simple way, we directly track the linkables which were
loaded into the interpreter whilst compiling a module. This is an
over-approximation but more robust wrt package dependencies changing.

4. Fix recompilation checking for dynamic object files. Now we actually
check if the dynamic object file exists when compiling with -dynamic-too

Fixes #19774 #19771 #19758 #17434 #11556 #9121 #8211 #16495 #7277 #16093

Matthew Pickering authored 3 years ago and Marge Bot committed 3 years ago

This commit modifies interface files so that *only* direct information
about modules and packages is stored in the interface file.

* Only direct module and direct package dependencies are stored in the
interface files.
* Trusted packages are now stored separately as they need to be checked
  transitively.
* hs-boot files below the compiled module in the home module are stored
  so that eps_is_boot can be calculated in one-shot mode without loading
  all interface files in the home package.
* The transitive closure of signatures is stored separately

This is important for two reasons

* Less recompilation is needed, as motivated by #16885, a lot of
redundant compilation was triggered when adding new imports deep in the
module tree as all the parent interface files had to be redundantly
updated.
* Checking an interface file is cheaper because you don't have to
perform a transitive traversal to check the dependencies are up-to-date.

In the code, places where we would have used the transitive closure, we
instead compute the necessary transitive closure. The closure is not
computed very often, was already happening in checkDependencies, and
was already happening in getLinkDeps.

Fixes #16885

-------------------------
Metric Decrease:
    MultiLayerModules
    T13701
    T13719
-------------------------

Fixed in #14759.

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

As noted in #14759, this triggers a warning in ListSetOps.

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

This reverts commit 76c8fd67.

This reverts commit 1cdc14f9.

This is causing non-deterministic testsuite output.

Austin Seipp authored 6 years ago and Ben Gamari committed 6 years ago

See `Note [Recompute abi-depends]` for more information.

Signed-off-by: Austin Seipp <aseipp@pobox.com>

Test Plan: `./validate`

Reviewers: bgamari, ezyang

Reviewed By: bgamari

Subscribers: tdammers, juhp, carter, alexbiehl, shlevy, cocreature,
rwbarton, thomie

GHC Trac Issues: #14381

Differential Revision: https://phabricator.haskell.org/D4159

rwbarton authored 8 years ago and Ben Gamari committed 8 years ago

The script I used is included as testsuite/driver/kill_extra_files.py,
though at this point it is for mostly historical interest.

Some of the tests in libraries/hpc relied on extra_files.py, so this
commit includes an update to that submodule.

One test in libraries/process also relies on extra_files.py, but we
cannot update that submodule so easily, so for now we special-case it
in the test driver.

We are now tracking the 2.0 branch.

Thomas Miedema authored 8 years ago and Ben Gamari committed 8 years ago

The `clean_cmd` and `extra_clean` setup functions don't do anything.
Remove them from .T files.

Created using https://github.com/thomie/refactor-ghc-testsuite. This
diff is a test for the .T-file parser/processor/pretty-printer in that
repository.

    find . -name '*.T' -exec ~/refactor-ghc-testsuite/Main "{}" \;

Tests containing inline comments or multiline strings are not modified.

Preparation for #12223.

Test Plan: Harbormaster

Reviewers: austin, hvr, simonmar, mpickering, bgamari

Reviewed By: mpickering

Subscribers: mpickering

Differential Revision: https://phabricator.haskell.org/D3000

GHC Trac Issues: #12223

This patch reverts the change introduced with
587dcccf and restores the previous
default output of GHC (i.e., show source path and object path for each
compiled module).

The -fhide-source-paths flag can be used to hide these paths and reduce
the line
noise.

Reviewers: gracjan, nomeata, austin, bgamari, simonmar, hvr

Reviewed By: hvr

Subscribers: thomie

Differential Revision: https://phabricator.haskell.org/D2728

GHC Trac Issues: #12851

Reviewers: simonmar, mpickering, austin, bgamari

Reviewed By: bgamari

Subscribers: mpickering, nomeata, thomie

Differential Revision: https://phabricator.haskell.org/D2679

GHC Trac Issues: #12807

There's a substantial bump to the haddock.Cabal allocation
stats, because we added 50% more modules, so of course allocations
are going to increase 50%. (But perhaps this is indicative of
some bad constant factor in Haddock related to modules.)

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Test Plan: validate

Reviewers: ggreif, austin, bgamari

Subscribers: thomie

Differential Revision: https://phabricator.haskell.org/D2442

This seems necessary after 9634e245 (#11569).