| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
| |
It hasn't existed since a2a67cd520b9841114d69a87a423dabcb3b4368e -- in
2009!
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The GlobalRdrEnv of a GHCI session changes in odd ways: New bindings are
not just added "to the end", but also "in the middle", namely when
changing the set of imports: These are treated as if they happened
before all bindings from the prompt, even those that happened earlier.
Previously, this meant that the `ic_rn_gbl_env` is recalculated from the
`ic_tythings`. But this wasteful if `ic_tythings` has many entries that
define the same unqualified name. By separately keeping track of a
`GlobalRdrEnv` of all the locally defined things we can speed this
operation up significantly.
This change improves `T14052Type` by 60% (It used to be 70%, but it
looks that !6723 already reaped some of the rewards).
But more importantly, it hopefully unblocks #20455, becaues with this
smarter caching, the change needed to fix that issue will no longer make
`T14052` explode. I hope.
It does regress `T14052` by 30%; caching isn’t free. Oh well.
Metric Decrease:
T14052Type
Metric Increase:
T14052
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
At the moment if `-dynamic-too` fails then we rerun the whole pipeline
as if we were just in `-dynamic` mode. I argue this is a misfeature and
we should remove the so-called `DT_Failed` mode.
In what situations do we fall back to `DT_Failed`?
1. If the `dyn_hi` file corresponding to a `hi` file is missing completely.
2. If the interface hash of `dyn_hi` doesn't match the interface hash of `hi`.
What happens in `DT_Failed` mode?
* The whole compiler pipeline is rerun as if the user had just passed `-dynamic`.
* Therefore `dyn_hi/dyn_o` files are used which don't agree with the
`hi/o` files. (As evidenced by `dynamicToo001` test).
* This is very confusing as now a single compiler invocation has
produced further `hi`/`dyn_hi` files which are different to each
other.
Why should we remove it?
* In `--make` mode, which is predominately used `DT_Failed` does not
work (#19782), there can't be users relying on this functionality.
* In `-c` mode, the recovery doesn't fix the root issue, which is the
`dyn_hi` and `hi` files are mismatched. We should instead produce an
error and pass responsibility to the build system using `-c` to ensure
that the prerequisites for `-dynamic-too` (dyn_hi/hi) files are there
before we start compiling.
* It is a misfeature to support use cases like `dynamicToo001` which
allow you to mix different versions of dynamic/non-dynamic interface
files. It's more likely to lead to subtle bugs in your resulting
programs where out-dated build products are used rather than a
deliberate choice.
* In practice, people are usually compiling with `-dynamic-too` rather
than separately with `-dynamic` and `-static`, so the build products
always match and `DT_Failed` is only entered due to compiler bugs (see
!6583)
What should we do instead?
* In `--make` mode, for home packages check during recompilation
checking that `dyn_hi` and `hi` are both present and agree, recompile
the modules if they do not.
* For package modules, when loading the interface check that `dyn_hi`
and `hi` are there and that they agree but fail with an
error message if they are not.
* In `--oneshot` mode, fail with an error message if the right files
aren't already there.
Closes #19782 #20446 #9176 #13616
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Before we would print
[1 of 3] Compiling T[boot] ( T.hs-boot, nothing, T.dyn_o )
Which was clearly wrong for two reasons.
1. No dynamic object file was produced for T[boot]
2. The file would be called T.dyn_o-boot if it was produced.
Fixes #20300
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ModLocation is the data type which tells you the locations of all the
build products which can affect recompilation. It is now computed in one
place and not modified through the pipeline. Important locations will
now just consult ModLocation rather than construct the dynamic object
path incorrectly.
* Add paths for dynamic object and dynamic interface files to
ModLocation.
* Always use the paths from mod location when looking for where to find
any interface or object file.
* Always use the paths in a ModLocation when deciding where to write an
interface and object file.
* Remove `dynamicOutputFile` and `dynamicOutputHi` functions which
*calculated* (incorrectly) the location of `dyn_o` and `dyn_hi` files.
* Don't set `outputFile_` and so-on in `enableCodeGenWhen`, `-o` and
hence `outputFile_` should not affect the location of object files in
`--make` mode. It is now sufficient to just update the ModLocation with
the temporary paths.
* In `hscGenBackendPipeline` don't recompute the `ModLocation` to
account for `-dynamic-too`, the paths are now accurate from the start
of the run.
* Rename `getLocation` to `mkOneShotModLocation`, as that's the only
place it's used. Increase the locality of the definition by moving it
close to the use-site.
* Load the dynamic interface from ml_dyn_hi_file rather than attempting
to reconstruct it in load_dynamic_too.
* Add a variety of tests to check how -o -dyno etc interact with each
other.
Some other clean-ups
* DeIOify mkHomeModLocation and friends, they are all pure functions.
* Move FinderOpts into GHC.Driver.Config.Finder, next to initFinderOpts.
* Be more precise about whether we mean outputFile or outputFile_: there
were many places where outputFile was used but the result shouldn't have
been affected by `-dyno` (for example the filename of the resulting
executable). In these places dynamicNow would never be set but it's
still more precise to not allow for this possibility.
* Typo fixes suffices -> suffixes in the appropiate places.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
WwOpts in WorkWrap.Utils initialised the wo_output_file field with the
result of outputFile dflags. This is misguided because outputFile is
only set when -o is specified, which is barely ever (and never in --make
mode).
It seems this is
just used to add more context to an error message, a more appropriate
thing to use I think would be a module name.
Fixes #20438
|
| |
|
|
|
| |
This test checks that we check for missing dynamic objects if
dynamic-too is enabled implicitly by the driver.
|
| |
|
|
|
| |
This "fixes" DT_Failed in --make mode, but only "fixes" because I still
believe DT_Failed is pretty broken.
|
| | |
|
| |
|
|
|
| |
We just need to check the flag here rather than read the variable which
indicates whether dynamic-too compilation has failed.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There is a latent issue in T16219 where -dynamic-too is enabled
when compiling a signature file which causes us to enter the DT_Failed
state because library-a-impl doesn't generate dyn_o files. Somehow this
used to work in 8.10 (that also entered the DT_Failed state)
We don't need dynamic object files when compiling a signature file but
the code loads interfaces, and if dynamic-too is enabled then it will
also try to load the dyn_hi file and check the two are consistent.
There is another hack to do with this in `GHC.Iface.Recomp`.
The fix for this test is to remove CABAL_MINIMAL_CONFIGURATION, which
stops cabal building shared libraries by default.
I'm of the opinion that the DT_Failed state indicates an error somewhere
so we should hard fail rather than this confusing (broken) rerun logic.
Whether this captures the original intent of #16219 is debateable, but
it's not clear how it was supposed to work in the first place if the
libraries didn't build dynamic object files. Module C imports module A,
which is from a library where shared objects are not built so the test
would never have worked anyway (if anything from A was used in a TH
splice).
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
PHASE 1: we never rewrite Concrete# evidence.
This patch migrates all the representation polymorphism checks to
the typechecker, using a new constraint form
Concrete# :: forall k. k -> TupleRep '[]
Whenever a type `ty` must be representation-polymorphic
(e.g. it is the type of an argument to a function), we emit a new
`Concrete# ty` Wanted constraint. If this constraint goes
unsolved, we report a representation-polymorphism error to the user.
The 'FRROrigin' datatype keeps track of the context of the
representation-polymorphism check, for more informative error messages.
This paves the way for further improvements, such as
allowing type families in RuntimeReps and improving the soundness
of typed Template Haskell. This is left as future work (PHASE 2).
fixes #17907 #20277 #20330 #20423 #20426
updates haddock submodule
-------------------------
Metric Decrease:
T5642
-------------------------
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In the old days the old HPT was used as an interface file cache when
using ghci. The HPT is a `ModuleEnv HomeModInfo` and so if you were
using hs-boot files then the interface file from compiling the .hs file
would be present in the cache but not the hi-boot file. This used to be
ok, because the .hi file used to just be a better version of the
.hi-boot file, with more information so it was fine to reuse it. Now the
source hash of a module is kept track of in the interface file and the
source hash for the .hs and .hs-boot file are correspondingly different
so it's no longer safe to reuse an interface file.
I took the decision to move the cache management of interface files to
GHCi itself, and provide an API where `load` can be provided with a list
of interface files which can be used as a cache. An alternative would be
to manage this cache somewhere in the HscEnv but it seemed that an API
user should be responsible for populating and suppling the cache rather
than having it managed implicitly.
Fixes #20217
|
| |
|
|
| |
Fixes #20508
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
this allows us to use a smarter implementation based on
`Data.IntSet.differenceWith`, which should do less work. Also, it will
unblock improvements to !6703.
The `OccEnv a` really denotes a set of `OccName`s. We are not using
`OccSet`, though, because that is an `OccEnv OccName`, and we in !6703
we want to use this with differently-valued `OccEnv`s. But `OccSet`s are
readily and safely coerced into `OccEnv`s.
There is no other use of `delLocalRdrEnvList` remaining, so removing
that.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
a number of functions exported by this module are (no longer) used, so
let’s remove them.
In particular, it no longer seems to be the case that type variables
have tag `'t'`, so removed the special handling when showing them.
* the use of `initTyVarUnique` was removed in 7babb1 (with the notable
commit message of "Before merging to HEAD we need to tidy up and write
a proper commit message.")
* `mkPseudoUniqueD`and `mkPseudoUniqueH` were added in 423d477, but never ever used?
* `mkCoVarUnique` was added in 674654, but never ever used?
|
| | |
|
