| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
| |
Explain that the kind of a data family instance must now be
fully determined by the header of the instance, and how one
might migrate code to account for this change.
Fixes #20527
|
|
|
|
| |
Add missing "Natural -> Integer -> Word#" rule.
|
|
|
|
| |
Fix #15547
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is the following find and replace:
- `rts/dist` -> `rts/dist-install` # for paths
- `rts_dist` -> `rts_dist-install` # for make rules and vars
- `,dist` -> `,dist-install` # for make, just in rts/ghc.mk`
Why do this? Does it matter when the RTS is just built once? The answer
is, yes, I think it does, because I want the distdir--stage
correspondence to be consistent.
In particular, for #17191 and continuing from
d5de970dafd5876ef30601697576167f56b9c132 I am going to make the headers
(`rts/includes`) increasingly the responsibility of the RTS (hence their
new location). However, those headers are current made for multiple
stages. This will probably become unnecessary as work on #17191
progresses and the compiler proper becomes more of a freestanding cabal
package (e.g. a library that can be downloaded from Hackage and built
without any autoconf). However, until that is finished, we have will
transitional period where the RTS and headers need to agree on dirs for
multiple stages.
I know the make build system is going away, but it's not going yet, so I
need to change it to unblock things :).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We have a function in #20510 that is small enough to get a stable unfolding in WW:
```hs
small :: Int -> Int
small x = go 0 x
where
go z 0 = z * x
go z y = go (z+y) (y-1)
```
But it appears we failed to use the WW'd RHS as the stable unfolding. As a result,
inlining `small` would expose the non-WW'd version of `go`. That appears to regress
badly in #19727 which is a bit too large to extract a reproducer from that is
guaranteed to reproduce across GHC versions.
The solution is to simply update the unfolding in `certainlyWillInline` with the
WW'd RHS.
Fixes #20510.
|
|
|
|
|
| |
Otherwise the instances aren't good list producers.
See Note [Stable Unfolding for list producers].
|
| |
|
|
|
|
|
| |
This turns the `static` flavour into the `+fully_static` flavour
transformer.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
- RTS and libdw
- SMP
- RTS ways
I am leaving them in the settings file because `--info` currently prints
all the fields in there, but in the future I do believe we should
separate the info GHC actually needs from "extra metadata". The latter
could go in `+RTS --info` and/or a separate file that ships with the RTS
for compile-time inspection instead.
|
|
|
|
|
|
|
|
|
| |
`manual-package-config` should not hard-code the distdir, and no
longer does
Elsewhere, we must continue to hard-code due to inconsitent distdir
names across stages, so we document this referring to the existing note
"inconsistent distdirs".
|
|
|
|
| |
(#20496)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch removes the following defaulting of type variables
in type and data families:
- type variables of kind RuntimeRep defaulting to LiftedRep
- type variables of kind Levity defaulting to Lifted
- type variables of kind Multiplicity defaulting to Many
It does this by passing "defaulting options" to the `defaultTyVars`
function; when calling from `tcTyFamInstEqnGuts` or
`tcDataFamInstHeader` we pass options that avoid defaulting.
This avoids wildcards being defaulted, which caused type families
to unexpectedly fail to reduce.
Note that kind defaulting, applicable only with -XNoPolyKinds,
is not changed by this patch.
Fixes #17536
-------------------------
Metric Increase:
T12227
-------------------------
|
|
|
|
| |
(#20263)
|
|
|
|
|
| |
It seems more clear to think of lines as LF-terminated rather than
LF-separated.
|
|
|
|
|
| |
I think this hasn't been a thing since
86054b4ab5125a8b71887b06786d0a428539fb9c, almost 10 years ago!
|
|
|
|
|
| |
It hasn't existed since a2a67cd520b9841114d69a87a423dabcb3b4368e -- in
2009!
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Users of `undefined` don’t want to see
```
files.hs: Prelude.undefined:
CallStack (from HasCallStack):
error, called at libraries/base/GHC/Err.hs:79:14 in base:GHC.Err
undefined, called at file.hs:151:19 in main:Main
```
but want to see
```
files.hs: Prelude.undefined:
CallStack (from HasCallStack):
undefined, called at file.hs:151:19 in main:Main
```
so let’s make that so.
The function for that is `withFrozenCallStack`, but that is not usable
here (module dependencies, and also not representation-polymorphic). And
even if it were, it could confuse GHC’s strictness analyzer, leading to
big regressions in some perf tests (T10421 in particular).
So after shuffling modules and definitions around, I eventually noticed
that the easiest way is to just not call `error` here.
Fixes #19886
|
|
|
|
|
| |
This allows us to use an Anchor with a DeltaPos in it when exact
printing.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch fixes some abundant reboxing of `DynFlags` in
`GHC.HsToCore.Match.Literal.warnAboutOverflowedLit` (which was the topic
of #19407) by introducing a Boxity analysis to GHC, done as part of demand
analysis. This allows to accurately capture ad-hoc unboxing decisions previously
made in worker/wrapper in demand analysis now, where the boxity info can
propagate through demand signatures.
See the new `Note [Boxity analysis]`. The actual fix for #19407 is described in
`Note [No lazy, Unboxed demand in demand signature]`, but
`Note [Finalising boxity for demand signature]` is probably a better entry-point.
To support the fix for #19407, I had to change (what was)
`Note [Add demands for strict constructors]` a bit
(now `Note [Unboxing evaluated arguments]`). In particular, we now take care of
it in `finaliseBoxity` (which is only called from demand analaysis) instead of
`wantToUnboxArg`.
I also had to resurrect `Note [Product demands for function body]` and rename
it to `Note [Unboxed demand on function bodies returning small products]` to
avoid huge regressions in `join004` and `join007`, thereby fixing #4267 again.
See the updated Note for details.
A nice side-effect is that the worker/wrapper transformation no longer needs to
look at strictness info and other bits such as `InsideInlineableFun` flags
(needed for `Note [Do not unbox class dictionaries]`) at all. It simply collects
boxity info from argument demands and interprets them with a severely simplified
`wantToUnboxArg`. All the smartness is in `finaliseBoxity`, which could be moved
to DmdAnal completely, if it wasn't for the call to `dubiousDataConInstArgTys`
which would be awkward to export.
I spent some time figuring out the reason for why `T16197` failed prior to my
amendments to `Note [Unboxing evaluated arguments]`. After having it figured
out, I minimised it a bit and added `T16197b`, which simply compares computed
strictness signatures and thus should be far simpler to eyeball.
The 12% ghc/alloc regression in T11545 is because of the additional `Boxity`
field in `Poly` and `Prod` that results in more allocation during `lubSubDmd`
and `plusSubDmd`. I made sure in the ticky profiles that the number of calls
to those functions stayed the same. We can bear such an increase here, as we
recently improved it by -68% (in b760c1f).
T18698* regress slightly because there is more unboxing of dictionaries
happening and that causes Lint (mostly) to allocate more.
Fixes #19871, #19407, #4267, #16859, #18907 and #13331.
Metric Increase:
T11545
T18698a
T18698b
Metric Decrease:
T12425
T16577
T18223
T18282
T4267
T9961
|
|
|
|
|
|
|
|
|
|
| |
A new feature requires Ghcide to be able to convert warnings to CLI
flags (WarningFlag -> String). This is most easily implemented in terms
of the internal function flagSpecOf, which uses an inefficient
implementation based on linear search through a linked list. This PR
derives Ord for WarningFlag, and replaces that list with a Map.
Closes #19087.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In #20539 we had a type
```hs
newtype Measured a = Measured { unmeasure :: () -> a }
```
and `isRecDataCon Measured` recursed into `go_arg_ty` for `(->) ()`, because
`unwrapNewTyConEtad_maybe` eta-reduced it. That triggered an assertion error a
bit later. Eta reducing the field type is completely wrong to do here! Just call
`unwrapNewTyCon_maybe` instead.
Fixes #20539 and adds a regression test T20539.
|
|
|
|
|
|
| |
This simplifies the code path for -j1 by not using the log queue queue
abstraction. The result is that trace output isn't interleaved with
other dump output like it can be with -j<N>.
|
|
|
|
|
| |
Fix the call to compilerConfig because it accepts 1-indexed stage
numbers. Also fixes `make stage=3`.
|
|
|
|
|
|
|
|
|
| |
Use an (Raw)PkgQual datatype instead of `Maybe FastString` to represent
package imports. Factorize the code that renames RawPkgQual into PkgQual
in function `rnPkgQual`. Renaming consists in checking if the FastString
is the magic "this" keyword, the home-unit unit-id or something else.
Bump haddock submodule
|
|
|
|
| |
We no longer need it after previous IndefUnitId refactoring.
|
|
|
|
|
|
|
| |
Now that Bignum predicates are inlined (!6696), we only need to add a
test.
Fix #19641
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Because uVar used eqType instead of tcEqType, it was possible
to accumulate a substitution that unified Type and Constraint.
For example, a call to `tc_unify_tys` with arguments
tys1 = [ k, k ]
tys2 = [ Type, Constraint ]
would first add `k = Type` to the substitution. That's fine, but then
the second call to `uVar` would claim that the substitution also
unifies `k` with `Constraint`. This could then be used to cause
trouble, as per #20521.
Fixes #20521
|
|
|
| |
Might fix #20526.
|
| |
|
|
|
|
|
|
| |
it is confusing to see what looks like it could be clever code, only to
see that it does precisely the same thing as the default methods.
Cleaning this up, to spare future readers the confusion.
|
|
|
|
|
|
|
|
|
| |
This somewhat fixes the annoyance of not getting any "useful" feedback
from a CI pipeline if you have a hlint failure. Now the hlint job runs
in parallel with the other CI jobs so the feedback is recieved at the
same time as other testsuite results.
Fixes #20507
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When we are not writing a ModIface to disk then the result can retain a
lot of stuff. For example, in the case I was debugging the DocDeclsMap
field was holding onto the entire HomePackageTable due to a single
unforced thunk. Therefore, now if we're not going to write the interface
then we still force deeply it in order to remove these thunks.
The fields in the data structure are not made strict because when we
read the field from the interface we don't want to load it immediately
as there are parts of an interface which are unused a lot of the time.
Also added a note to explain why not all the fields in a ModIface field
are strict.
The result of this is being able to load Agda in ghci and not leaking
information across subsequent reloads.
|
|
|
|
|
|
|
|
| |
Allow T12545 to increase because it only happens on CI with dwarf
enabled and probably not related to this patch.
Metric Increase:
T12545
|
|
|
|
|
|
|
|
|
| |
T17516 allocations increase by 48% because Integer's predicates are
inlined in some Ord instance methods. These methods become too big to be
inlined while they probably should: this is tracked in #20516.
Metric Increase:
T17516
|
| |
|
|
|
|
|
|
|
|
| |
In order to do this I thought it was prudent to change the list type to
a bag type to avoid doing a lot of premature work in plusGRE because of
++.
Fixes #19201
|
|
|
|
|
|
|
|
|
|
| |
This change means the HomeModInfo cache isn't retained until the end of
upsweep and each cached interface can be collected immediately after its
module is compiled.
The result is lower peak memory usage when using GHCi.
For Agda it reduced peak memory usage from about 1600M to 1200M.
|
|
|
|
|
|
|
|
| |
The main change is to install the necessary build dependencies into an
environment file using `caball install --lib`.
Also updates the nofib submodule with a few fixes needed for the job to
work.
|
|
|
|
|
|
|
|
|
| |
Previously the logic which called ghc-pkg failed to account for the fact
that the executable name may be prefixed with a triple. Moreover, the
call must occur before we delete the settings file as ghc-pkg needs the
latter.
Fixes #20267.
|
| |
|
|
|
|
|
| |
At the moment the note just covers three important invariants but now
there is a place to add more to if we think of them.
|
|
|
|
|
| |
Previously we failed to quote various paths in Hadrian's installation
Makefile, resulting in #20506.
|
| |
|
| |
|
|
|
|
| |
Close #20443.
|
|
|
|
|
|
| |
This test triggers the bad code path identified by #20509 where an entry
into the EPS caused by importing Control.Applicative will retain a stale
HomePackageTable.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This hack inserted for backpack caused a very bad leak when using
-fno-code where EPS entries would end up retaining stale
HomePackageTables. For any interactive user, such as HLS, this is really
bad as once the entry makes it's way into the EPS then it's there for
the rest of the session.
This is a temporary fix which "solves" the issue by filtering the HPT to
only the part which is needed for the hack to work, but in future we
want to separate out hole modules from the HPT entirely to avoid needing
to do this kind of special casing.
-------------------------
Metric Decrease:
MultiLayerModulesDefsGhci
-------------------------
|
|
|
|
|
|
|
|
|
|
|
| |
Targets are long-lived through GHC sessions so we don't want to end up
retaining
In particular in 'guessTarget', the call to `unitIdOrHomeUnit` was
retaining reference to an entire stale HscEnv, which in turn retained
reference to a stale HomePackageTable. Making the fields strict forces
that place promptly and helps ensure that mistakes like this don't
happen again.
|
|
|
|
|
|
| |
This test checks to see whether a signature can depend on another home
module. Whether it should or not is up for debate, see #20509 for
more details.
|