| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
mode backpack edges
Backpack instantiations need to be typechecked to make sure that the
arguments fit the parameters. `tcRnInstantiateSignature` checks
instantiations with concrete modules, while `tcRnCheckUnit` checks
instantiations with free holes (signatures in the current modules).
Before this change, it worked that `tcRnInstantiateSignature` was called
after typechecking the argument module, see `HscMain.hsc_typecheck`,
while `tcRnCheckUnit` was called in `unsweep'` where-bound in
`GhcMake.upsweep`. `tcRnCheckUnit` was called once per each
instantiation once all the argument sigs were processed. This was done
with simple "to do" and "already done" accumulators in the fold.
`parUpsweep` did not implement the change.
With this change, `tcRnCheckUnit` instead is associated with its own
node in the `ModuleGraph`. Nodes are now:
```haskell
data ModuleGraphNode
-- | Instantiation nodes track the instantiation of other units
-- (backpack dependencies) with the holes (signatures) of the current package.
= InstantiationNode InstantiatedUnit
-- | There is a module summary node for each module, signature, and boot module being built.
| ModuleNode ExtendedModSummary
```
instead of just `ModSummary`; the `InstantiationNode` case is the
instantiation of a unit to be checked. The dependencies of such nodes
are the same "free holes" as was checked with the accumulator before.
Both versions of upsweep on such a node call `tcRnCheckUnit`.
There previously was an `implicitRequirements` function which would
crawl through every non-current-unit module dep to look for all free
holes (signatures) to add as dependencies in `GHC.Driver.Make`. But this
is no good: we shouldn't be looking for transitive anything when
building the graph: the graph should only have immediate edges and the
scheduler takes care that all transitive requirements are met.
So `GHC.Driver.Make` stopped using `implicitRequirements`, and instead
uses a new `implicitRequirementsShallow`, which just returns the
outermost instantiation node (or module name if the immediate dependency
is itself a signature). The signature dependencies are just treated like
any other imported module, but the module ones then go in a list stored
in the `ModuleNode` next to the `ModSummary` as the "extra backpack
dependencies". When `downsweep` creates the mod summaries, it adds this
information too.
------
There is one code quality, and possible correctness thing left: In
addition to `implicitRequirements` there is `findExtraSigImports`, which
says something like "if you are an instantiation argument (you are
substituted or a signature), you need to import its things too". This
is a little non-local so I am not quite sure how to get rid of it in
`GHC.Driver.Make`, but we probably should eventually.
First though, let's try to make a test case that observes that we don't
do this, lest it actually be unneeded. Until then, I'm happy to leave it
as is.
------
Beside the ability to use `-j`, the other major user-visibile side
effect of this change is that that the --make progress log now includes
"Instantiating" messages for these new nodes. Those also are numbered
like module nodes and count towards the total.
------
Fixes #17188
Updates hackage submomdule
Metric Increase:
T12425
T13035
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, we let-bound an identifier to use to carry
the erroring evidence for an out-of-scope variable. But
this failed for levity-polymorphic out-of-scope variables,
leading to a panic (#17812). The new plan is to use
a mutable update to just write the erroring expression directly
where it needs to go.
Close #17812.
Test case: typecheck/should_compile/T17812
|
| |
|
|
|
|
| |
In eb629fab I accidentally got rid of it when inlining tons of helpers.
Closes #19004
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch significantly refactors key renamer datastructures (primarily Avail
and GlobalRdrElt) in order to treat DuplicateRecordFields in a more robust way.
In particular it allows the extension to be used with pattern synonyms (fixes
where mangled record selector names could be printed instead of field labels
(e.g. with -Wpartial-fields or hole fits, see new tests).
The key idea is the introduction of a new type GreName for names that may
represent either normal entities or field labels. This is then used in
GlobalRdrElt and AvailInfo, in place of the old way of representing fields
using FldParent (yuck) and an extra list in AvailTC.
Updates the haddock submodule.
|
| |
|
|
|
|
| |
patterns
Fixes #19109.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Given a kind signature
type T :: forall k. k -> forall k. k -> blah
data T a b = ...
where those k's have the same unique (which is possible;
see #19093) we were giving the tyConBinders in tycon T the same
unique, which caused chaos.
Fix is simple: ensure uniqueness when decomposing the kind signature.
See GHC.Tc.Gen.HsType.zipBinders
|
| |
|
|
|
|
| |
See `Note [Scoping of named wildcards]` in GHC.Hs.Type
This lack of documentation came up in #19051.
|
| | |
|
| |
|
|
| |
Fix #19082, #17045
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Consider
```hs
data Ex where
Ex :: e -> Int -> Ex
f :: Ex -> Int
f (Ex e n) = e `seq` n + 1
```
Worker/wrapper should build the following worker for `f`:
```hs
$wf :: forall e. e -> Int# -> Int#
$wf e n = e `seq` n +# 1#
```
But previously it didn't, because `Ex` binds an existential.
This patch lifts that condition. That entailed having to instantiate
existential binders in `GHC.Core.Opt.WorkWrap.Utils.mkWWstr` via
`GHC.Core.Utils.dataConRepFSInstPat`, requiring a bit of a refactoring
around what is now `DataConPatContext`.
CPR W/W still won't unbox DataCons with existentials.
See `Note [Which types are unboxed?]` for details.
I also refactored the various `tyCon*DataCon(s)_maybe` functions in
`GHC.Core.TyCon`, deleting some of them which are no longer needed
(`isDataProductType_maybe` and `isDataSumType_maybe`).
I cleaned up a couple of call sites, some of which weren't very explicit
about whether they cared for existentials or not.
The test output of `T18013` changed, because we now unbox the `Rule`
data type. Its constructor carries existential state and will be
w/w'd now. In the particular example, the worker functions inlines right
back into the wrapper, which then unnecessarily has a (quite big) stable
unfolding. I think this kind of fallout is inevitable;
see also Note [Don't w/w inline small non-loop-breaker things].
There's a new regression test case `T18982`.
Fixes #18982.
|
| |
|
|
| |
I also took the liberty to refactor the logic around `ruleFVs`.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
This gives a small increase in performance under most circumstances.
For single threaded GC the improvement is on the order of 1-2%.
For multi threaded GC the results are quite noisy but seem to
fall into the same ballpark.
Fixes #16499
|
| |
|
|
| |
A workaround for #19099.
|
| |
|
|
| |
Semigroup too of course
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
Previously we would push large objects and compact regions to the mark
queue during the deadlock detect GC, resulting in failure to detect
deadlocks.
|
| |
|
|
| |
Pull the cold non-moving allocation path out of alloc_for_copy.
|
| |
|
|
|
|
| |
Previously the deadlock-detection promotion logic in alloc_for_copy was
just plain wrong: it failed to fire when gct->evac_gen_no !=
oldest_gen->gen_no. The fix is simple: move the
|
| |
|
|
|
| |
When performing a deadlock-detection GC we must ensure that all objects
end up in the non-moving generation. Assert this in scavenge.
|
| |
|
|
|
| |
Previously an incorrect semicolon meant that we would fail to call
busy_wait_nop when spinning.
|
| | |
|
| |
|
|
| |
The unapplied arguments were not printed out.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch delivers on #17656, by entirel killing off the complex
floatEqualities mechanism. Previously, floatEqualities would float an
equality out of an implication, so that it could be solved at an outer
level. But now we simply do unification in-place, without floating the
constraint, relying on level numbers to determine untouchability.
There are a number of important new Notes:
* GHC.Tc.Utils.Unify Note [Unification preconditions]
describes the preconditions for unification, including both
skolem-escape and touchability.
* GHC.Tc.Solver.Interact Note [Solve by unification]
describes what we do when we do unify
* GHC.Tc.Solver.Monad Note [The Unification Level Flag]
describes how we control solver iteration under this new scheme
* GHC.Tc.Solver.Monad Note [Tracking Given equalities]
describes how we track when we have Given equalities
* GHC.Tc.Types.Constraint Note [HasGivenEqs]
is a new explanation of the ic_given_eqs field of an implication
A big raft of subtle Notes in Solver, concerning floatEqualities,
disappears.
Main code changes:
* GHC.Tc.Solver.floatEqualities disappears entirely
* GHC.Tc.Solver.Monad: new fields in InertCans, inert_given_eq_lvl
and inert_given_eq, updated by updateGivenEqs
See Note [Tracking Given equalities].
* In exchange for updateGivenEqa, GHC.Tc.Solver.Monad.getHasGivenEqs
is much simpler and more efficient
* I found I could kill of metaTyVarUpdateOK entirely
One test case T14683 showed a 5.1% decrease in compile-time
allocation; and T5631 was down 2.2%. Other changes were small.
Metric Decrease:
T14683
T5631
|
| | |
|
| |
|
|
|
| |
This fixes test Linear14. The code in Unify.hs was always using
multiplicity Many instead of a new metavariable.
|
| |
|
|
| |
Close #19064
|
| |
|
|
|
|
|
| |
* -Wincomplete-uni-patterns
* -Wincomplete-record-updates
See https://gitlab.haskell.org/ghc/ghc/-/issues/15656
|
| |
|
|
|
| |
Ensure it is ready for -Wincomplete-uni-patterns and
-Wincomplete-record-updates in -Wall
|
| |
|
|
|
|
|
|
| |
The algorithm described in the referenced paper uses this slightly
weaker atomic op.
This is the first "exotic" cas we're using. I've added a macro in the
<ORDERING>_OP style to match existing ones.
|
| |
|
|
|
|
|
|
|
|
| |
This patch makes the desugarer rewrite
noinline (f d) --> noinline f d
This makes 'noinline' much more reliable: see #18995
It's explained in the improved Note [noinlineId magic]
in GHC.Types.Id.Make
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Provoked by #18987, this patch adds a missing zonkQuickLook of
app_res_rho in tcApp.
Most of the time this zonk is unnecesary. In fact, I can't think of a
concrete case where it is needed -- hence no test. But even if it
isn't necessary, the reasoning that allows it to be omitted is very
subtle. So I've put it in.
However, adding this zonk does /not/ affect the emitted constraints,
so the reported symptoms for #18987 remain, but harmlessly so, and now
documented in a new Note [Instantiation variables are short lived]
in GHC.Tc.Gen.App.
No change in behaviour, no tests.
|
| | |
|
| |
|
|
|
|
|
|
| |
Fixes two ancient bugs in the testsuite driver makefiles due to
insufficient quoting. I have no idea how these went unnoticed for so
long.
Thanks to @tomjaguarpaw for testing.
|
| |
|
|
| |
Fixes #18840.
|
| |
|
|
|
| |
THREADED_RTS was previously misspelled as THREADEDED_RTS.
Fixes #19057.
|
| |
|
|
|
|
|
|
|
|
| |
See Note [Infinitary substitution in lookup] in GHC.Core.InstEnv
and Note [Unification result] in GHC.Core.Unify.
Test case: typecheck/should_compile/T190{44,52}
Close #19044
Close #19052
|
| |
|
|
|
|
|
|
|
| |
This commit renames parser's Error and Warning types (and their
constructors) to have a 'Ps' prefix, so that this would play nicely
when more errors and warnings for other phases of the pipeline will
be added. This will make more explicit which is the particular type
of error and warning we are dealing with, and will be more informative
for users to see in the generated Haddock.
|
| |
|
|
|
|
|
| |
This commit splits the GHC.Driver.Env module creating a separate
GHC.Driver.Env.Types module where HscEnv and Hsc would live. This
will pave the way to the structured error values by avoiding one
boot module later down the line.
|
| |
|
|
|
| |
The elf size is 32bit on 32bit builds and 64 otherwise.
We just upcast to 64bits before printing now.
|
| | |
|
| |
|
|
|
| |
StgWord has different widths on 32/64bit. So use the proper type
instead.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Issue #18914 revealed that `GeneralizedNewtypeDeriving` would generate code
that mentions unbound type variables, which is dangerously fragile. The
problem (and fix) is described in the new `Wrinkle: Use HsOuterExplicit`
in `Note [GND and QuantifiedConstraints]`. The gist of it: make sure to
put the top-level `forall`s in `deriving`-generated instance signatures in an
`HsOuterExplicit` to ensure that they scope over the bodies of methods
correctly. A side effect of this process is that it will expand any type
synonyms in the instance signature, which will surface any `forall`s that
are hidden underneath type synonyms (such as in the test case for #18914).
While I was in town, I also performed some maintenance on `NewHsTypeX`, which
powers `GeneralizedNewtypeDeriving`:
* I renamed `NewHsTypeX` to `HsCoreTy`, which more accurately describes its
intended purpose (#15706). I also made `HsCoreTy` a type synonym instead of
a newtype, as making it a distinct data type wasn't buying us much.
* To make sure that mistakes similar to #18914 do not occur later, I added an
additional validity check when renaming `HsCoreTy`s that complains if an
`HsCoreTy`s contains an out-of-scope type variable. See the new
`Note [Renaming HsCoreTys]` in `GHC.Rename.HsType` for the details.
Fixes #15706. Fixes #18914. Bumps the `haddock` submodule.
|
| | |
|
