| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
This makes the Haddocks easier to understand.
|
| | |
|
| |
|
|
| |
Also drops the unused TREC_COMMITTED transaction state.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes a bug that @JunmingZhao42 and I noticed while working on her
MMTK port. Specifically, in stg_stop_thread we used stg_enter_info as a
sentinel at the tail of a stack after a thread has completed. However,
stg_enter_info expects to have a two-field payload, which we do not
push. Consequently, if the GC ends up somehow the stack it will attempt
to interpret data past the end of the stack as the frame's fields,
resulting in unsound behavior.
To fix this I eliminate this hacky use of `stg_stop_thread` and instead
introduce a new stack frame type, `stg_dead_thread_info`. Not only does
this eliminate the potential for the previously mentioned memory
unsoundness but it also more clearly captures the intended structure of
the dead threads' stacks.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Drop libtool logic from gen-dll, allowing us to drop the remaining logic
from the `configure` script.
Strangely, this appears to reliably reduce compiler allocations of
T16875 on Windows.
Closes #18826.
Metric Decrease:
T16875
|
| |
|
|
|
| |
GHC no longers uses libtool for linking and therefore this is no longer
necessary.
|
| |
|
|
|
|
|
|
|
| |
Previously we supported building statically-linked executables using
libtool. However, this was dropped in
91262e75dd1d80f8f28a3922934ec7e59290e28c in favor of using ar/ranlib
directly. Consequently we can drop this logic.
Fixes #18826.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As described in Note [Wired-in exceptions are not CAFfy], a small set of
built-in exception closures get special treatment in the code generator,
being declared as non-CAFfy despite potentially containing CAF
references. The original intent of this treatment for the RTS to then
add StablePtrs for each of the closures, ensuring that they are not
GC'd. However, this logic was not applied consistently and eventually
removed entirely in 951c1fb0. This lead to #21141.
Here we fix this bug by reintroducing the StablePtrs and document the
status quo.
Closes #21141.
|
| | |
|
| |
|
|
|
|
|
| |
To ensure that the build benefits from Hadrian's usual logic for building
packages, avoiding #21409.
Closes #21409.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously `test.mk` would try to determine whether the dynamic,
profiling, and vanilla library ways are available by searching for
`PrimOpWrappers.{,dyn_,p_}hi` in directory reported by `ghc-pkg field
ghc-prim library-dirs`. However, this is extremely fragile as
there is no guarantee that there is only one library directory. To
handle the case of multiple `library-dirs` correct we would
have to carry out the delicate task of tokenising the directory list (in
shell, no less).
Since this isn't a task that I am eager to solve, I have rather moved
the detection logic into the testsuite driver and instead perform a test
compilation in each of the ways. This should be more robust than the
previous approach.
I stumbled upon this while fixing #20579.
|
| | |
|
| |
|
|
|
|
|
|
| |
The package-specific include directories in
Settings.Builders.Common.cIncludeDirs are now redundant since they now
come from Cabal.
Closes #20566.
|
| |
|
|
|
|
|
|
| |
Previously we only took `extraLibDirs` and friends from the package
description, ignoring any contribution from the `LocalBuildInfo`. Fix
this.
Fixes #20566.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Second fix to #21391. It turned out that we missed calling
bringFloatedDictsIntoScope when specialising imports, which
led to the same bug as before.
I refactored to move that call to a single place, in specCalls,
so we can't forget it.
This meant making `FloatedDictBinds` into its own type, pairing
the dictionary bindings themselves with the set of their binders.
Nicer this way.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The "candidates" passed to decideMonoTyVars can contain coercion holes.
This is because we might well decide to quantify over some unsolved
equality constraints, as long as they are not definitely insoluble.
In that situation, decideMonoTyVars was passing a set of type variables
that was not closed over kinds to closeWrtFunDeps, which was tripping
up an assertion failure.
Fixes #21404
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
The assertion in reportWanteds that we aren't suppressing all the
Wanted constraints was too strong: it might be the case that we are
inside an implication, and have already reported an unsolved Wanted
from outside the implication. It is possible that all Wanteds inside
the implication have been rewritten by the outer Wanted, so we shouldn't
throw an assertion failure in that case.
Fixes #21405
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* In CoreToStg, the application 'RUBBISH[rep] x' was simplified
to 'RUBBISH[rep]'. But it is possible that the result of the function
is represented differently than the function.
* In Unarise, 'LitRubbish (primRepToType prep)'
is incorrect: LitRubbish takes a RuntimeRep such as IntRep,
while primRepToType returns a type such as Any @(TYPE IntRep). Use
primRepToRuntimeRep instead.
This code is never run in the testsuite.
* In StgToByteCode, all rubbish literals were assumed to be boxed.
This code predates representation-polymorphic RubbishLit and I think
it was not updated.
I don't have a testcase for any of those issues, but the code looks
wrong.
|
| |
|
|
| |
Previously only -dcore-lint was enabled.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Here we set GHC_ENVIRONMENT="-" to ensure that GHC invocations of tests
don't pick up a user's local package environment.
Fixes #21365.
Metric Decrease:
T10421
T12234
T12425
T13035
T16875
T9198
|
| |
|
|
|
|
|
|
| |
Previously Hadrian's installation makefile would assume that the string
`xxx` did not appear in the installation path. This would of course
break for some users.
Fixes #21402.
|
| |
|
|
|
|
| |
As of #18487 we no longer support 32-bit Windows.
Fixes #21372.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
This can be disabled by `-fno-dump-with-ways` if not desired.
Finally we will be able to look at both profiled and non-profiled dumps
when compiling with dump flags and we compile in both ways.
|
| |
|
|
|
|
|
| |
Fixes #20940
Metric Decrease:
T18698a
|
| | |
|
| |
|
|
|
|
| |
While debugging it is very useful to be able to determine whether a
given info table is a stack frame or not. We have spare bits in the
closure flags array anyways, use one for this information.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In GHC.Core.Opt.Specialise.bindAuxiliaryDict we were unnecessarily
calling `extendInScope` to bring into scope variables that were
/already/ in scope. Worse, GHC.Core.Subst.extendInScope strangely
deleted the newly-in-scope variables from the substitution -- and that
was fatal in #21391.
I removed the redundant calls to extendInScope.
More ambitiously, I changed GHC.Core.Subst.extendInScope (and cousins)
to stop deleting variables from the substitution. I even changed the
names of the function to extendSubstInScope (and cousins) and audited
all the calls to check that deleting from the substitution was wrong.
In fact there are very few such calls, and they are all about
introducing a fresh non-in-scope variable. These are "OutIds"; it is
utterly wrong to mess with the "InId" substitution.
I have not added a Note, because I'm deleting wrong code, and it'd be
distracting to document a bug.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For I assume performance reasons we don't record no-op replacements
during unarise. This lead to problems with code like this:
f = \(Eta_B0 :: VoidType) x1 x2 ->
... let foo = \(Eta_B0 :: LiftedType) -> g x y Eta_B0
in ...
Here we would record the outer Eta_B0 as void rep, but would not
shadow Eta_B0 inside `foo` because this arg is single-rep and so
doesn't need to replaced. But this means when looking at occurence
sites we would check the env and assume it's void rep based on the
entry we made for the (no longer in scope) outer `Eta_B0`.
Fixes #21396 and the ticket has a few more details.
|
| |
|
|
|
|
| |
Every Id was storing a boolean whether it could be levity-polymorphic.
This information is no longer needed since representation-checking
has been moved to the typechecker.
|
| |
|
|
|
|
|
|
|
| |
This provides a way to set the Opt_KeepRawTokenStream from the command
line, allowing exact print annotation users to see exactly what is
produced for a given parsed file, when used in conjunction with
-ddump-parsed-ast
Discussed in #19706, but this commit does not close the issue.
|
| |
|
|
|
| |
Previously the interpreter's handling of `RET_BCO` stack frames would
throw away the tag of the returned closure. This resulted in #21390.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
The order in which ways are provided doesn't matter,
so we use a data structure with the appropriate semantics to
represent ways.
Fixes #21378
|
| |
|
|
|
|
|
| |
This will mean T9208 when run with lint will return a lint error instead
of resulting in a panic.
Fixes #21117
|
| |
|
|
|
|
|
|
| |
This change makes it clear that it's the definition rather than any
usage which is a problem, and that rules defined in other modules will
still be used to do rewrites.
Fixes #20923
|
| |
|
|
|
|
|
|
| |
interesting dictionary
I extracted the checks from `Note [Type determines value]` into its own
function, so that we share the logic properly. Then I made sure that we
actually call `typeDeterminesValue` everywhere we check for `interestingDict`.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In #19644, we discovered that the ClassOp/DFun rules from
Note [ClassOp/DFun selection] inhibit transitive specialisation in a scenario
like
```
class C a where m :: Show b => a -> b -> ...; n :: ...
instance C Int where m = ... -- $cm :: Show b => Int -> b -> ...
f :: forall a b. (C a, Show b) => ...
f $dC $dShow = ... m @a $dC @b $dShow ...
main = ... f @Int @Bool ...
```
After we specialise `f` for `Int`, we'll see `m @a $dC @b $dShow` in the body of
`$sf`. But before this patch, Specialise doesn't apply the ClassOp/DFun rule to
rewrite to a call of the instance method for `C Int`, e.g., `$cm @Bool $dShow`.
As a result, Specialise couldn't further specialise `$cm` for `Bool`.
There's a better example in `Note [Specialisation modulo dictionary selectors]`.
This patch enables proper Specialisation, as follows:
1. In the App case of `specExpr`, try to apply the CalssOp/DictSel rule on the
head of the application
2. Attach an unfolding to freshly-bound dictionary ids such as `$dC` and
`$dShow` in `bindAuxiliaryDict`
NB: Without (2), (1) would be pointless, because `lookupRule` wouldn't be able
to look into the RHS of `$dC` to see the DFun.
(2) triggered #21332, because the Specialiser floats around dictionaries without
accounting for them in the `SpecEnv`'s `InScopeSet`, triggering a panic when
rewriting dictionary unfoldings.
Fixes #19644 and #21332.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I completely rewrote our Notes surrounding eta-reduction. The new entry point is
`Note [Eta reduction makes sense]`.
Then I went on to extend the Simplifier to maintain an evaluation context in the
form of a `SubDemand` inside a `SimplCont`. That `SubDemand` is useful for doing
eta reduction according to `Note [Eta reduction based on evaluation context]`,
which describes how Demand analysis, Simplifier and `tryEtaReduce` interact to
facilitate eta reduction in more scenarios.
Thus we fix #21261.
ghc/alloc perf marginally improves (-0.0%). A medium-sized win is when compiling
T3064 (-3%). It seems that haddock improves by 0.6% to 1.0%, too.
Metric Decrease:
T3064
|
| |
|
|
| |
Fix #19891
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Before this patch, the lexer did a truly roundabout thing with the dot:
1. look up the varsym in reservedSymsFM and turn it into ITdot
2. under OverloadedRecordDot, turn it into ITvarsym
3. in varsym_(prefix|suffix|...) turn it into ITvarsym, ITdot, or
ITproj, depending on extensions and whitespace
Turns out, the last step is sufficient to handle the dot correctly.
This patch removes the first two steps.
|
| |
|
|
|
|
|
| |
There was a missing SymCo in pushCoercionIntoLambda. Currently
this codepath is only used with rewrite rules, so this bug managed
to slip by, but trying to use pushCoercionIntoLambda in other contexts
revealed the bug.
|
| | |
|
| | |
|
