| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
Not forcing this one place will result in GHCi using 2x memory on a
reload.
|
| | |
|
| |
|
|
|
|
| |
It's better to remove the modules first before performing the
typecheckLoop as otherwise you can end up with thunks which reference
stale HomeModInfo which are difficult to force due to the knot-tie.
|
| |
|
|
|
|
|
|
|
| |
This patch makes some operations to do with HomePackageTable stricter
* Adding a new entry into the HPT would not allow the old HomeModInfo to be
collected because the function used by insertWith wouldn't be forced.
* We're careful to force the new MVar value before it's inserted into
the global MVar as otherwise we retain references to old entries.
|
| |
|
|
|
| |
There's no reason for them to be lazy, and in particular we would like
to make sure the old_hpt field is evaluated.
|
| |
|
|
|
| |
The Module field can end up retaining part of a large structure and is
always calculated by projection.
|
| |
|
|
| |
Otherwise you end up retaining the whole old HPT when reloading in GHCi.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It is quite easy to end up accidently retaining a KnotVars, which
contains pointers to a stale TypeEnv because they are placed in the
HscEnv.
One place in particular we have to be careful is when loading a module
into the EPS in `--make` mode, we have to remove the reference to
KnotVars as otherwise the interface loading thunks will forever retain
reference to the KnotVars which are live at the time the interface was
loaded.
These changes do not go as far as to enforce the invariant described in
Note [KnotVar invariants]
* At the end of upsweep, there should be no live KnotVars
but at least improve the situation.
This is left for future work (#20491)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In GHCi, by default the ModIface is not written to disk, this can
leave a thunk which retains a TyCon which ends up retaining a great deal
more on the heap.
For example, here is the retainer trace from ghc-debug.
```
...
many other closures
...
<TyCon:GHC.Core.TyCon:compiler/GHC/Core/TyCon.hs:1755:34-97>
Just 0x423162aaa8 <Maybe:GHC.Core.TyCon:compiler/GHC/Core/TyCon.hs:(1936,11)-(1949,13)>
FamilyTyCon 0x4231628318 0x4210e06260 0x4231628328 0x4231628340 0x421730a398 0x4231628358 0x4231628380 0x4231628390 0x7f0f5a171d18 0x7f0f7b1d7850 0x42316283a8 0x7f0f7b1d7830 <TyCon:GHC.Core.TyCon:compiler/GHC/Cor
e/TyCon.hs:1948:30-32>
_thunk( ) 0x4231624000 <OccName:GHC.Iface.Make:compiler/GHC/Iface/Make.hs:724:22-43>
NotOrphan 0x42357d8ed8 <IsOrphan:GHC.Iface.Make:compiler/GHC/Iface/Make.hs:724:12-43>
IfaceFamInst 0x4210e06260 0x42359aed10 0x4210e0c6b8 0x42359aed28 <IfaceFamInst:GHC.Iface.Make:>
```
Making the field strict squashes this retainer leak when using GHCi.
|
| |
|
|
| |
Bumps bootstrap compiler to GHC 9.0.1.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously it was unclear whether req_shared_libs should require:
* that the platform supports dynamic library loading,
* that GHC supports dynamic linking of Haskell code, or
* that the dyn way libraries were built
Clarify by splitting the predicate into two:
* `req_dynamic_lib_support` demands that the platform support dynamic
linking
* `req_dynamic_hs` demands that the GHC support dynamic linking of
Haskell code on the target platform
Naturally `req_dynamic_hs` cannot be true unless
`req_dynamic_lib_support` is also true.
|
| |
|
|
|
| |
Previously this attempt at suppressing make's -s flag would mangle
otherwise valid arguments.
|
| |
|
|
| |
There was nothing dynamic about this test.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
Previously we would depend upon `grep ... | head -n1`. In principle this
should work, but on Alpine Linux `grep` complains when its stdout stream
has been closed.
|
| |
|
|
|
| |
Suppress output from diff to eliminate unnecessary
environmental-dependence.
|
