| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As shown in #20200, and described in
Note [Simplifying recursive modules],
it is possible to encounter an occurrence of a GlobalId that
is bound in the module being compiled. Lint complains, quite
properly.
This patch updates GHC.Core.Opt.Simplify.Env.refineFromScope so
that it looks up a GlobalId in the InScopeSet if the module is
the one being compiled. That in turn means we need to know what
is the module being compiled, hence the new st_module field in
SimplTopEnv.
Test case is simplCore/should_compile/AgdaDatatypes
|
| |
|
|
|
| |
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?
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Locations can be quite long-lived so it's important that things which
live in locations, such as annotations are forced promptly. Otherwise
they end up retaining the entire PState, as evidenced by this retainer
trace:
```
PState 0x4277ce6cd8 0x4277ce6d00 0x7f61f12d37d8 0x7f61f12d37d8 0x7f61f135ef78 0x4277ce6d48 0x4277ce6d58 0x4277ce6d70 0x4277ce6d58 0x4277ce6d88 0x4277ce6da0 0x7f61f29782f0 0x7f61cd16b440 0x7f61cd16b440 0x7f61d00f8d18 0x7f61f296d290 0x7f61cd16b440 0x7f61d00f8d18 0x7f61cd16b4a8 0x7f61f135ef78 0x4277ce6db8 0x4277ce6dd0 0x7f61f134f358 0 3 <PState:GHC.Parser.Lexer:_build-ipe/stage1/compiler/build/GHC/Parser/Lexer.hs:3779:46>
_thunk( ) 0x4277ce6280 0x4277ce68a0 <([LEpaComment], [LEpaComment]):GHC.Parser.Lexer:>
_thunk( ) 0x4277ce6568 <EpAnnComments:GHC.Parser.Lexer:compiler/GHC/Parser/Lexer.x:2306:19-40>
_thunk( ) 0x4277ce62b0 0x4277ce62c0 0x4277ce6280 0x7f61f287fc58 <EpAnn AnnList:GHC.Parser:_build-ipe/stage1/compiler/build/GHC/Parser.hs:12664:13-32>
SrcSpanAnn 0x4277ce6060 0x4277ce6048 <SrcSpanAnn':GHC.Parser:_build-ipe/stage1/compiler/build/GHC/Parser.hs:12664:3-35>
L 0x4277ce4e70 0x428f8c9158 <GenLocated:GHC.Data.BooleanFormula:compiler/GHC/Data/BooleanFormula.hs:40:23-29>
0x428f8c8318 : 0x428f8c8300 <[]:GHC.Base:libraries/base/GHC/Base.hs:1316:16-29>
Or 0x428f8c7890 <BooleanFormula:GHC.Data.BooleanFormula:compiler/GHC/Data/BooleanFormula.hs:40:23-29>
IfConcreteClass 0x7f61cd16b440 0x7f61cd16b440 0x428f8c7018 0x428f8c7030 <IfaceClassBody:GHC.Iface.Make:compiler/GHC/Iface/Make.hs:(640,12)-(645,13)>
```
Making these few places strict is sufficient for now but there are
perhaps more places which will need strictifying in future.
-------------------------
Metric Increase:
parsing001
-------------------------
|
| |
|
|
|
|
|
|
|
| |
Ensure the AddSemiAnn items appear in increasing order, so that if
they are converted to delta format they are still in the correct
order.
Prior to this the exact printer sorted by Span, which is meaningless
for EpaDelta locations.
|
| |
|
|
|
|
| |
else the output may depend on the input order, which seems it may depend
on the concrete Uniques, which is causing headaches when including test
cases about that.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I encountered an error that says
```
Cannot load -dynamic objects when GHC is built the normal way
To fix this, either:
(1) Use -fexternal-interpreter, or
(2) Build the program twice: once the normal way, and then
with -dynamic using -osuf to set a different object file suffix.
```
Or it could say
```
(2) Use -dynamic-too
```
|
| |
|
|
|
|
|
|
|
|
| |
while working on GHCi stuff, e.g. `GHC.Runtime.Eval.Types`, I observed a
fair amount of modules being recompiled that I didn’t expect to depend
on this, from byte code interpreters to linkers. Turns out that the
rather simple `BreakInfo` type is all these modules need from the
`GHC.Runtime.Eval.*` hierarchy, so by moving that into its own file we
make the dependency tree wider and shallower, which is probably worth
it.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously it would fail with this error:
```
if [ -L wrappers/ghc ]; then echo "ghc is a symlink"; fi
ghc is a symlink
cp: target 'dir/bin/ghc' is not a directory
make: *** [Makefile:197: install_wrappers] Error 1
```
which is because the install path contains a space.
Fixes #20506
|
| |
|
|
|
|
|
|
|
|
| |
Backpack used to initialise the logger before obtaining the
DynFlags. This meant that logging options (such as dump flags)
were not set.
Initialising the logger after the session flags have been set
fixes the issue.
fixes #20396
|
| |
|
|
|
| |
Sadly, autoconf cannot warn when it encounters an undefined macro and
therefore this bug went unnoticed for altogether far too long.
|
| |
|
|
|
|
|
|
|
|
|
| |
haddock: deterministic SCC
Updates haddock submodule
Metric Increase:
haddock.Cabal
haddock.base
haddock.compiler
|
| | |
|
| |
|
|
|
|
| |
don't need them
hadrian: build optional dependencies with test compiler
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Issues #19072, #17728, #20176
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
previously, the `shadowNames` function would take `[GreName]`. This has
confused me for two reasons:
* Why `GreName` and not `Name`? Does the difference between a normal
name and a field name matter? The code of `shadowNames` shows that it
does not, but really its better if the type signatures says so.
* Why `Name` and not `OccName`? The point of `shadowNames` is to shadow
_unqualified names_, at least in the two use cases I am aware of
(names defined on the GHCI prompt or in TH splices).
The code of `shadowNames` used to have cases that peek at the module
of the given name and do something if that module appears in the
`GlobalRdrElt`, but I think these cases are dead code, I don’t see
how they could occur in the above use cases. Also, I replaced them
with `errors` and GHC would still validate. Hence removing this code
(yay!)
This change also allows `shadowNames` to accept an `OccSet` instead,
which allows for a faster implemenation; I’ll try that separately. This
in stead might help with !6703.
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
Some platforms (e.g. RISC-V) require linking against libatomic for some
(e.g. sub-word-sized) atomic operations.
Fixes #19119.
|
