| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| |
|
|
| |
This was only needed for SPARC's synthetic instructions.
|
| |
|
|
|
| |
Now that RegPair is gone we no longer need to pay for the additional
box.
|
| |
|
|
| |
SPARC was its last and only user.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The main purpose of this patch is to attach a SkolemInfo directly to
each SkolemTv. This fixes the large number of bugs which have
accumulated over the years where we failed to report errors due to
having "no skolem info" for particular type variables. Now the origin of
each type varible is stored on the type variable we can always report
accurately where it cames from.
Fixes #20969 #20732 #20680 #19482 #20232 #19752 #10946
#19760 #20063 #13499 #14040
The main changes of this patch are:
* SkolemTv now contains a SkolemInfo field which tells us how the
SkolemTv was created. Used when reporting errors.
* Enforce invariants relating the SkolemInfoAnon and level of an implication (ic_info, ic_tclvl)
to the SkolemInfo and level of the type variables in ic_skols.
* All ic_skols are TcTyVars -- Check is currently disabled
* All ic_skols are SkolemTv
* The tv_lvl of the ic_skols agrees with the ic_tclvl
* The ic_info agrees with the SkolInfo of the implication.
These invariants are checked by a debug compiler by
checkImplicationInvariants.
* Completely refactor kcCheckDeclHeader_sig which kept
doing my head in. Plus, it wasn't right because it wasn't skolemising
the binders as it decomposed the kind signature.
The new story is described in Note [kcCheckDeclHeader_sig]. The code
is considerably shorter than before (roughly 240 lines turns into 150
lines).
It still has the same awkward complexity around computing arity as
before, but that is a language design issue.
See Note [Arity inference in kcCheckDeclHeader_sig]
* I added new type synonyms MonoTcTyCon and PolyTcTyCon, and used
them to be clear which TcTyCons have "finished" kinds etc, and
which are monomorphic. See Note [TcTyCon, MonoTcTyCon, and PolyTcTyCon]
* I renamed etaExpandAlgTyCon to splitTyConKind, becuase that's a
better name, and it is very useful in kcCheckDeclHeader_sig, where
eta-expansion isn't an issue.
* Kill off the nasty `ClassScopedTvEnv` entirely.
Co-authored-by: Simon Peyton Jones <simon.peytonjones@gmail.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
As #20746 showed, the demand analyser behaved badly in a key I/O
library (`GHC.IO.Handle.Text`), by unnessarily boxing and reboxing.
This patch adjusts the subtle function deferAfterPreciseException;
it's quite easy, just a bit subtle.
See the new Note [deferAfterPreciseException]
And this MR deals only with Problem 2 in #20746.
Problem 1 is still open.
|
| |
|
|
|
|
|
| |
Fix a simple omission in GHC.Tc.Solver.Canonical.solveForAll,
where we ended up with the wrong TcLclEnv captured in an implication.
Result: unhelpful error message (#21006)
|
| |
|
|
|
|
|
|
|
| |
The second component is supposed to be "insoluble equalities arising
from givens". But we were getting wanteds too; and that led to an
outright duplication of constraints. It's not harmful, but it's not
right either.
I came across this when debugging something else. Easily fixed.
|
| |
|
|
|
|
|
|
| |
Some warnings have been there "forever" and I could not trace back the
exact genesis, so I wrote "since at least 5.04".
The flag `helpful-errors` could have been added in 7.2 already. I
wrote 7.4 since I have no 7.2 available and it is not recognized by 7.0.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
This fixes #20981. See Note [restoreLclEnv vs setLclEnv]
in GHC.Tc.Utils.Monad.
I also use updLclEnv rather than get/set when I can, because it's
then much clearer that it's an update rather than an entirely new
TcLclEnv coming from who-knows-where.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
`markNominal` is repsonsible for setting the roles of type variables
that appear underneath an `AppTy` to be nominal. However, `markNominal`
previously did not expand type synonyms, so in a data type like this:
```hs
data M f a = MkM (f (T a))
type T a = Int
```
The `a` in `M f a` would be marked nominal, even though `T a` would simply
expand to `Int`. The fix is simple: call `coreView` as appropriate in
`markNominal`. This is much like the fix for #14101, but in a different spot.
Fixes #20999.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
As #20921 showed, with partial signatures, it is helpful to use the
same algorithm (namely findInferredDiff) for
* picking the constraints to retain for the /group/
in Solver.decideQuantification
* picking the contraints to retain for the /individual function/
in Bind.chooseInferredQuantifiers
This is still regrettably declicate, but it's a step forward.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch addresses #20988 by refactoring the way the
occurrence analyser deals with lambdas.
Previously it used collectBinders to split off a group of binders,
and deal with them together. Now I deal with them one at a time
in occAnalLam, which allows me to skip casts easily. See
Note [Occurrence analysis for lambda binders]
about "lambda-groups"
This avoidance of splitting out a list of binders has some good
consequences. Less code, more efficient, and I think, more clear.
The Simplifier needed a similar change, now that lambda-groups
can inlude casts. It turned out that I could simplify the code
here too, in particular elminating the sm_bndrs field of StrictBind.
Simpler, more efficient.
Compile-time metrics improve slightly; here are the ones that are
+/- 0.5% or greater:
Baseline
Test Metric value New value Change
--------------------------------------------------------------------
T11303b(normal) ghc/alloc 40,736,702 40,543,992 -0.5%
T12425(optasm) ghc/alloc 90,443,459 90,034,104 -0.5%
T14683(normal) ghc/alloc 2,991,496,696 2,956,277,288 -1.2%
T16875(normal) ghc/alloc 34,937,866 34,739,328 -0.6%
T17977b(normal) ghc/alloc 37,908,550 37,709,096 -0.5%
T20261(normal) ghc/alloc 621,154,237 618,312,480 -0.5%
T3064(normal) ghc/alloc 190,832,320 189,952,312 -0.5%
T3294(normal) ghc/alloc 1,604,674,178 1,604,608,264 -0.0%
T5321FD(normal) ghc/alloc 270,540,489 251,888,480 -6.9% GOOD
T5321Fun(normal) ghc/alloc 300,707,814 281,856,200 -6.3% GOOD
WWRec(normal) ghc/alloc 588,460,916 585,536,400 -0.5%
geo. mean -0.3%
Metric Decrease:
T5321FD
T5321Fun
|
| |
|
|
|
|
|
|
|
|
|
| |
If `doFloatFromRhs` is `False` then the result from `prepareBinding`
should not be used. Previously it was in ways that are silly (but not
completly wrong, as the simplifier would clean that up again, so no
test case).
This was spotted by Simon during a phone call.
Fixes #20976
|
| |
|
|
|
|
|
|
|
|
| |
This patch fixes #19790 by making the rule matcher do on-the-fly
eta reduction. See Note [Eta reduction the target] in GHC.Core.Rules
I found I also had to careful about casts when matching; see
Note [Casts in the target] and Note [Casts in the template]
Lots more comments and Notes in the rule matcher
|
| | |
|
| |
|
|
| |
Fixes #20995
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The insert_overlapping used in lookupInstEnv used to return different
results depending on the order in which instances were processed.
The problem was that we could end up discarding an overlapping instance
in favour of a more specific non-overlapping instance. This is a
problem because, even though we won't choose the less-specific instance
for matching, it is still useful for pruning away other instances,
because it has the overlapping flag set while the new instance doesn't.
In insert_overlapping, we now keep a list of "guard" instances, which
are instances which are less-specific that one that matches (and hence
which we will discard in the end), but want to keep around solely for
the purpose of eliminating other instances.
Fixes #20946
|
| |
|
|
| |
This fixes #20938.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch makes the following types levity-polymorphic in their
last argument:
- Array# a, SmallArray# a, Weak# b, StablePtr# a, StableName# a
- MutableArray# s a, SmallMutableArray# s a,
MutVar# s a, TVar# s a, MVar# s a, IOPort# s a
The corresponding primops are also made levity-polymorphic, e.g.
`newArray#`, `readArray#`, `writeMutVar#`, `writeIOPort#`, etc.
Additionally, exception handling functions such as `catch#`, `raise#`,
`maskAsyncExceptions#`,... are made levity/representation-polymorphic.
Now that Array# and MutableArray# also work with unlifted types,
we can simply re-define ArrayArray# and MutableArrayArray# in terms
of them. This means that ArrayArray# and MutableArrayArray# are no
longer primitive types, but simply unlifted newtypes around Array# and
MutableArrayArray#.
This completes the implementation of the Pointer Rep proposal
https://github.com/ghc-proposals/ghc-proposals/pull/203
Fixes #20911
-------------------------
Metric Increase:
T12545
-------------------------
-------------------------
Metric Decrease:
T12545
-------------------------
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Previously, `DeriveGeneric` would look up the fixity of a data constructor
using `getFixityEnv`, but this is subtly incorrect for data constructors
defined in external modules. This sort of situation can happen with
`StandaloneDeriving`, as noticed in #20994. In fact, the same bug has occurred
in the past in #9830, and while that bug was fixed for `deriving Read` and
`deriving Show`, the fix was never extended to `DeriveGeneric` due to an
oversight. This patch corrects that oversight.
Fixes #20994.
|
| |
|
|
|
|
|
|
| |
As requested by Simon after review of !7342.
I also took liberty to define the `Functor` instance by hand, as the derived one
subverts the invariants maintained by the pattern synonym (as already stated in
`Note [The one-shot state monad trick]`).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This gives users the choice to enable __compact_unwind sections
when linking. These were previously hardcoded to be removed.
This can be used to solved the problem "C++ does not catch
exceptions when used with Haskell-main and linked by ghc",
https://gitlab.haskell.org/ghc/ghc/-/issues/11829
It does not change the default behavior, because I can not
estimate the impact this would have.
When Apple first introduced the compact unwind ABI, a number of
open source projects have taken the easy route of disabling it,
avoiding errors or even just warnings shortly after its
introduction.
Since then, about a decade has passed, so it seems quite possible
that Apple itself, and presumably many programs with it, have
successfully switched to the new format, to the point where the
old __eh_frame section support is in disrepair. Perhaps we should
get along with the program, but for now we can test the waters
with this flag, and use it to fix packages that need it.
|
| |
|
|
|
|
|
| |
Newer lld versions may include vendor info in --version output and
thus the version string may not start with ‘LLD’.
Fixes #20907
|
| |
|
|
| |
Closed #20904
|
| |
|
|
|
|
| |
I found it weird that most of the combinators weren't actually strict. Making
`pure` strict in the state should hopefully give Nested CPR an easier time to
unbox the nested state.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The simplest way to do this seemed to be to persist the whole type in
the extension field from the typechecker so that the few relevant places
* Desugaring can work out the return type by splitting this type rather
than calling `dsExpr` (slightly more efficient).
* hsExprType can just return the correct type.
* Zonking has to now zonk the type as well
The other option we considered was wiring in StaticPtr but that is
actually quite tricky because StaticPtr refers to StaticPtrInfo which
has field selectors (which we can't easily wire in).
Fixes #20150
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
Avoid requiring to pass DynFlags to mkDataConRep/buildDataCon. When we
load an interface file, these functions don't use the flags.
This is preliminary work to decouple the loader from the type-checker
for #14335.
|
| |
|
|
|
|
| |
(Fixes #10616 and #10617)
Co-authored-by: Roland Senn <rsx@bluewin.ch>
|
| |
|
|
| |
This makes it more similar to pprTrace, pprPanic etc.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The `GHC.Tc.Plugin.newWanted` function takes a `CtLoc` as an argument,
but it used to discard the location information, keeping only
the `CtOrigin`. It would then retrieve the source location from the
`TcM` environment using `getCtLocM`.
This patch changes this so that `GHC.Tc.Plugin.newWanted` passes on
the full `CtLoc`. This means that authors of type-checking plugins
no longer need to manually set the `CtLoc` environment in the `TcM`
monad if they want to create a new Wanted constraint with the given
`CtLoc` (in particular, for setting the `SrcSpan` of an emitted
constraint). This makes the `newWanted` function consistent with
`newGiven`, which always used the full `CtLoc` instead of using
the environment.
Fixes #20895
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Uses of a TyCon in a kind signature required users to enable
DataKinds, which didn't make much sense, e.g. in
type U = Type
type MyMaybe (a :: U) = MyNothing | MyJust a
Now the DataKinds error is restricted to data constructors;
the use of kind-level type constructors is instead gated behind
-XKindSignatures.
This patch also adds a convenience pattern synonym for patching
on both a TyCon or a TcTyCon stored in a TcTyThing, used in
tcTyVar and tc_infer_id.
fixes #20873
|
| |
|
|
| |
that note was removed in 4196969c53c55191e644d9eb258c14c2bc8467da
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We noticed that the structure of CoreUnfolding could leave double the
amount of CoreExprs which were retained in the situation where the
template but not all the predicates were forced. This observation was
then confirmed using ghc-debug:
```
(["ghc:GHC.Core:App","ghc-prim:GHC.Types:True","THUNK_1_0","THUNK_1_0","THUNK_1_0"],Count 237)
(["ghc:GHC.Core:App","ghc-prim:GHC.Types:True","THUNK_1_0","THUNK_1_0","ghc-prim:GHC.Types:True"],Count 1)
(["ghc:GHC.Core:Case","ghc-prim:GHC.Types:True","THUNK_1_0","THUNK_1_0","THUNK_1_0"],Count 12)
(["ghc:GHC.Core:Cast","ghc-prim:GHC.Types:True","THUNK_1_0","THUNK_1_0","BLACKHOLE"],Count 1)
(["ghc:GHC.Core:Cast","ghc-prim:GHC.Types:True","THUNK_1_0","THUNK_1_0","THUNK_1_0"],Count 78)
(["ghc:GHC.Core:Cast","ghc-prim:GHC.Types:True","THUNK_1_0","ghc-prim:GHC.Types:False","THUNK_1_0"],Count 1)
(["ghc:GHC.Core:Cast","ghc-prim:GHC.Types:True","ghc-prim:GHC.Types:False","THUNK_1_0","THUNK_1_0"],Count 3)
(["ghc:GHC.Core:Cast","ghc-prim:GHC.Types:True","ghc-prim:GHC.Types:True","THUNK_1_0","THUNK_1_0"],Count 1)
(["ghc:GHC.Core:Lam","ghc-prim:GHC.Types:True","THUNK_1_0","THUNK_1_0","BLACKHOLE"],Count 31)
(["ghc:GHC.Core:Lam","ghc-prim:GHC.Types:True","THUNK_1_0","THUNK_1_0","THUNK_1_0"],Count 4307)
(["ghc:GHC.Core:Lam","ghc-prim:GHC.Types:True","THUNK_1_0","THUNK_1_0","ghc-prim:GHC.Types:True"],Count 6)
(["ghc:GHC.Core:Let","ghc-prim:GHC.Types:True","THUNK_1_0","THUNK_1_0","THUNK_1_0"],Count 29)
(["ghc:GHC.Core:Lit","ghc-prim:GHC.Types:True","THUNK_1_0","THUNK_1_0","ghc-prim:GHC.Types:True"],Count 1)
(["ghc:GHC.Core:Tick","ghc-prim:GHC.Types:True","THUNK_1_0","THUNK_1_0","THUNK_1_0"],Count 36)
(["ghc:GHC.Core:Var","ghc-prim:GHC.Types:True","THUNK_1_0","THUNK_1_0","THUNK_1_0"],Count 1)
(["ghc:GHC.Core:Var","ghc-prim:GHC.Types:True","ghc-prim:GHC.Types:False","THUNK_1_0","THUNK_1_0"],Count 6)
(["ghc:GHC.Core:Var","ghc-prim:GHC.Types:True","ghc-prim:GHC.Types:False","ghc-prim:GHC.Types:True","THUNK_1_0"],Count 2)
```
Where we can see that the first argument is forced but there are still
thunks remaining which retain the old expr.
For my test case (a very big module, peak of 3 000 000 core terms) this
reduced peak memory usage by 1G (12G -> 11G).
Fixes #20905
|
| |
|
|
|
|
|
|
| |
Use primOpId instead of mkPrimOpId in a few places to benefit from
Id caching.
I had to mess a little bit with the module hierarchy to fix cycles and
to avoid adding too many new dependencies to count-deps tests.
|
| |
|
|
|
|
| |
SmallArray doesn't perform bounds check (faster).
Make primop tags start at 0 to avoid index arithmetic.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
When quoting (using a TH single or double quote) a built-in
name such as the list constructor (:), we didn't always check
that the resulting 'Name' was in the correct namespace.
This patch adds a check in GHC.Rename.Splice to ensure
we get a Name that is in the term-level/type-level namespace,
when using a single/double tick, respectively.
Fixes #20884.
|
| |
|
|
| |
This yields a small, but measurable, performance improvement.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 completes the fix for #20779 / !7123.
Beforehand, the program worked by accident because the two versions of
the library happened to be ordered properly (due to how the hashes were
computed). In the real world I observed them being the other way around
which meant the final lookup failed because we weren't filtering for
visibility.
I modified the test so that it failed (and it's fixed by this patch).
|
