| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
This fixes #21236.
|
|
|
|
| |
Fixes #21950
|
|
|
|
|
| |
Instead of `` `cast` <Co:11> :: (Some -> Really -> Large Type)``
simply print `` `cast` <Co:11> :: ... ``
|
|
|
|
| |
Fixes #21894
|
|
|
|
| |
Fixes #21918
|
|
|
|
|
|
|
|
|
| |
This patch fixes #21806 by rectifying an incorrect claim about
the usage of kind variables in the header of a data declaration with
a standalone kind signature.
It also adds some clarifications about the number of parameters expected
in GADT declarations and in type family declarations.
|
|
|
|
| |
Fixes #21866
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The hadrian executable depends on QuickCheck for building, meaning this
library (and its dependencies) will need to be built for bootstrapping
GHC in the future. Building QuickCheck, however, can require
TemplateHaskell. When building a statically linking GHC toolchain,
TemplateHaskell can be tricky to get to work, and cross-compiling
TemplateHaskell doesn't work at all without -fexternal-interpreter,
so QuickCheck introduces an element of fragility to GHC's bootstrap.
Since the selftest rules are the only part of hadrian that need
QuickCheck, we can easily eliminate this bootstrap dependency when
required by introducing a `selftest` flag guarding the rules' inclusion.
Closes #8699.
|
|
|
|
|
|
|
|
|
| |
Residency monitoring under the non-moving collector is quite
conservative (e.g. the reported value is larger than reality) since
otherwise we would need to block on concurrent collection. Skip a few
tests that are sensitive to residency.
(cherry picked from commit 6880e4fbf728c04e8ce83e725bfc028fcb18cd70)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes a rather subtle bug in the logic responsible for scavenging
objects evacuated to the non-moving generation. In particular, objects
can be allocated into the non-moving generation by two ways:
a. evacuation out of from-space by the garbage collector
b. direct allocation by the mutator
Like all evacuation, objects moved by (a) must be scavenged, since they
may contain references to other objects located in from-space. To
accomplish this we have the following scheme:
* each nonmoving segment's block descriptor has a scan pointer which
points to the first object which has yet to be scavenged
* the GC tracks a set of "todo" segments which have pending scavenging
work
* to scavenge a segment, we scavenge each of the unmarked blocks
between the scan pointer and segment's `next_free` pointer.
We skip marked blocks since we know the allocator wouldn't have
allocated into marked blocks (since they contain presumably live
data).
We can stop at `next_free` since, by
definition, the GC could not have evacuated any objects to blocks
above `next_free` (otherwise `next_free wouldn't be the first free
block).
However, this neglected to consider objects allocated by path (b).
In short, the problem is that objects directly allocated by the mutator
may become unreachable (but not swept, since the containing segment is
not yet full), at which point they may contain references to swept objects.
Specifically, we observed this in #21885 in the following way:
1. the mutator (specifically in #21885, a `lockCAF`) allocates an object
(specifically a blackhole, which here we will call `blkh`; see Note
[Static objects under the nonmoving collector] for the reason why) on
the non-moving heap. The bitmap of the allocated block remains 0
(since allocation doesn't affect the bitmap) and the containing
segment's (which we will call `blkh_seg`) `next_free` is advanced.
2. We enter the blackhole, evaluating the blackhole to produce a result
(specificaly a cons cell) in the nursery
3. The blackhole gets updated into an indirection pointing to the cons
cell; it is pushed to the generational remembered set
4. we perform a GC, the cons cell is evacuated into the nonmoving heap
(into segment `cons_seg`)
5. the cons cell is marked
6. the GC concludes
7. the CAF and blackhole become unreachable
8. `cons_seg` is filled
9. we start another GC; the cons cell is swept
10. we start a new GC
11. something is evacuated into `blkh_seg`, adding it to the "todo" list
12. we attempt to scavenge `blkh_seg` (namely, all unmarked blocks
between `scan` and `next_free`, which includes `blkh`). We attempt to
evacuate `blkh`'s indirectee, which is the previously-swept cons cell.
This is unsafe, since the indirectee is no longer a valid heap
object.
The problem here was that the scavenging logic *assumed* that (a) was
the only source of allocations into the non-moving heap and therefore
*all* unmarked blocks between `scan` and `next_free` were evacuated.
However, due to (b) this is not true.
The solution is to ensure that that the scanned region only encompasses
the region of objects allocated during evacuation. We do this by
updating `scan` as we push the segment to the todo-segment list to
point to the block which was evacuated into.
Doing this required changing the nonmoving scavenging implementation's
update of the `scan` pointer to bump it *once*, instead of after
scavenging each block as was done previously. This is because we may end
up evacuating into the segment being scavenged as we scavenge it. This
was quite tricky to discover but the result is quite simple,
demonstrating yet again that global mutable state should be used
exceedingly sparingly.
Fixes #21885
(cherry picked from commit 0b27ea23efcb08639309293faf13fdfef03f1060)
|
|
|
|
|
|
|
|
| |
It can often be useful during debugging to be able to determine the
state of a nonmoving segment. Introduce some state, enabled by DEBUG, to
track this.
(cherry picked from commit 40e797ef591ae3122ccc98ab0cc3cfcf9d17bd7f)
|
|
|
|
| |
(cherry picked from commit 19f8fce3659de3d72046bea9c61d1a82904bc4ae)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We no longer generate .s files anyway.
Metric Decrease:
MultiLayerModules
T10421
T13035
T13701
T14697
T16875
T18140
T18304
T18923
T9198
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There was an assert error, as Gergo pointed out in #21896.
I fixed this by adding an InScopeSet argument to tcUnifyTyWithTFs.
And also to GHC.Core.Unify.niFixTCvSubst.
I also took the opportunity to get a couple more InScopeSets right,
and to change some substTyUnchecked into substTy.
This MR touches a lot of other files, but only because I also took the
opportunity to introduce mkInScopeSetList, and use it.
|
|
|
|
|
| |
This file is just a place to accumlate notes about particular
benchmarks, so that I don't keep re-inventing the wheel.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch addresses #21831, point 2. See
Note [generaliseDictPats] in SpecConstr
I took the opportunity to refactor the construction of specialisation
rules a bit, so that the rule name says what type we are specialising
at.
Surprisingly, there's a 20% decrease in compile time for test
perf/compiler/T18223. I took a look at it, and the code size seems the
same throughout. I did a quick ticky profile which seemed to show a
bit less substitution going on. Hmm. Maybe it's the "don't do
eta-expansion in stable unfoldings" patch, which is part of the
same MR as this patch.
Anyway, since it's a move in the right direction, I didn't think it
was worth looking into further.
Metric Decrease:
T18223
|
|
|
|
|
|
| |
I think this change will make little difference except to reduce
clutter. But that's it -- if it causes problems we can switch it
on again.
|
|
|
|
| |
This fixes (1) in #21831. Easy, obviously correct.
|
|
|
|
|
|
|
|
|
| |
When bootstrapping GHC 9.4.*, the build will fail when configuring
ghc-cabal as part of the make based build system due to this upper
bound, as Cabal has been updated to a 3.8 release.
Reference #21914, see especially
https://gitlab.haskell.org/ghc/ghc/-/issues/21914#note_444699
|
|
|
|
| |
Fixes #21902.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On Windows, we create multiple levels of wrappers for GHCi which ultimately
execute ghc --interactive. In order to handle console events properly, each of
these wrappers must call FreeConsole() in order to hand off event processing to
the child process. See #14150.
In addition to this, FreeConsole must only be called from interactive processes (#13411).
This commit makes two changes to fix this situation:
1. The hadrian wrappers generated using `hadrian/bindist/cwrappers/version-wrapper.c` call `FreeConsole`
if the CPP flag INTERACTIVE_PROCESS is set, which is set when we are generating a wrapper for GHCi.
2. The GHCi wrapper in `driver/ghci/` calls the `ghc-$VER.exe` executable which is not wrapped rather
than calling `ghc.exe` is is wrapped on windows (and usually non-interactive, so can't call `FreeConsole`:
Before:
ghci-$VER.exe calls ghci.exe which calls ghc.exe which calls ghc-$VER.exe
After:
ghci-$VER.exe calls ghci.exe which calls ghc-$VER.exe
|
|
|
|
|
|
|
| |
Gergo points out (#21801) that GHC.Core.Opt.Arity.tryEtaReduce was
making an ill-formed cast. It didn't matter, because the subsequent
guard discarded it; but still worth fixing. Spurious warnings are
distracting.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch fixes #21888, and simplifies finaliseArgBoxities
by eliminating the (recently introduced) data type FinalDecision.
A delicate interaction meant that this patch
commit d1c25a48154236861a413e058ea38d1b8320273f
Date: Tue Jul 12 16:33:46 2022 +0100
Refactor wantToUnboxArg a bit
make worker/wrapper go into an infinite loop. This patch
fixes it by narrowing the handling of case (B) of
Note [Boxity for bottoming functions], to deal only the
arguemnts that are type variables. Only then do we drop
the trimBoxity call, which is what caused the bug.
I also
* Added documentation of case (B), which was previously
completely un-mentioned. And a regression test,
T21888a, to test it.
* Made unboxDeeplyDmd stop at lazy demands. It's rare anyway
for a bottoming function to have a lazy argument (mainly when
the data type is recursive and then we don't want to unbox
deeply). Plus there is Note [No lazy, Unboxed demands in
demand signature]
* Refactored the Case equation for dmdAnal a bit, to do less
redundant pattern matching.
|
|
|
|
|
|
|
|
|
|
|
| |
GHC doesn't consistently require the ConstraintKinds extension to
be enabled, as it allows programs such as type families returning
a constraint without this extension.
MR !7784 fixes this infelicity, but breaking user programs was deemed
to not be worth it, so we document it instead.
Fixes #21061.
|
|
|
|
| |
See #21859
|
|
|
|
|
|
|
|
|
|
|
|
| |
Approved by: https://github.com/haskell/core-libraries-committee/issues/61
This adds a default implementation for `mempty` and `(<>)` along
with a matching `MINIMAL` pragma so that `Semigroup` and `Monoid`
instances can be defined in terms of `sconcat` / `mconcat`.
The description for each class has also been updated to include the
equivalent set of laws for the `sconcat`-only / `mconcat`-only
instances.
|
| |
|
|
|
|
| |
Fixes DeepSubsumption08
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This MR adds the language extension -XDeepSubsumption, implementing
GHC proposal #511. This change mitigates the impact of GHC proposal
The changes are highly localised, by design. See Note [Deep subsumption]
in GHC.Tc.Utils.Unify.
The main changes are:
* Add -XDeepSubsumption, which is on by default in Haskell98 and Haskell2010,
but off in Haskell2021.
-XDeepSubsumption largely restores the behaviour before the "simple subsumption" change.
-XDeepSubsumpition has a similar flavour as -XNoMonoLocalBinds:
it makes type inference more complicated and less predictable, but it
may be convenient in practice.
* The main changes are in:
* GHC.Tc.Utils.Unify.tcSubType, which does deep susumption and eta-expanansion
* GHC.Tc.Utils.Unify.tcSkolemiseET, which does deep skolemisation
* In GHC.Tc.Gen.App.tcApp we call tcSubTypeNC to match the result
type. Without deep subsumption, unifyExpectedType would be sufficent.
See Note [Deep subsumption] in GHC.Tc.Utils.Unify.
* There are no changes to Quick Look at all.
* The type of `withDict` becomes ambiguous; so add -XAllowAmbiguousTypes to
GHC.Magic.Dict
* I fixed a small but egregious bug in GHC.Core.FVs.varTypeTyCoFVs, where
we'd forgotten to take the free vars of the multiplicity of an Id.
* I also had to fix tcSplitNestedSigmaTys
When I did the shallow-subsumption patch
commit 2b792facab46f7cdd09d12e79499f4e0dcd4293f
Date: Sun Feb 2 18:23:11 2020 +0000
Simple subsumption
I changed tcSplitNestedSigmaTys to not look through function arrows
any more. But that was actually an un-forced change. This function
is used only in
* Improving error messages in GHC.Tc.Gen.Head.addFunResCtxt
* Validity checking for default methods: GHC.Tc.TyCl.checkValidClass
* A couple of calls in the GHCi debugger: GHC.Runtime.Heap.Inspect
All to do with validity checking and error messages. Acutally its
fine to look under function arrows here, and quite useful a test
DeepSubsumption05 (a test motivated by a build failure in the
`lens` package) shows.
The fix is easy. I added Note [tcSplitNestedSigmaTys].
|
| |
|
|
|
|
|
|
|
|
|
| |
The way record updates are typechecked/desugared changed in MR !7981.
Because we desugar in the typechecker to a simple case expression, the
pattern match checker becomes able to spot the long-distance information
and avoid emitting an incorrect pattern match warning.
Fixes #21360
|
|
|
|
|
|
|
| |
This adds a test for #21871, which was fixed by the No Skolem Info
rework (MR !7105).
Fixes #21871
|
|
|
|
|
|
|
| |
The documentation was moved in a10584e8df9b346cecf700b23187044742ce0b35
but this one occurrence was note updated.
Finally closes #21164.
|
|
|
|
|
| |
GHC has a somewhat dizzying array of UTF-8 implementations. This note
describes why this is the case.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Here we copy a subset of the UTF-8 implementation living in `ghc-boot`
into `base`, with the intent of dropping the former in the future. For
this reason, the `ghc-boot` copy is now CPP-guarded on
`MIN_VERSION_base(4,18,0)`.
Naturally, we can't copy *all* of the functions defined by `ghc-boot` as
some depend upon `bytestring`; we rather just copy those which only
depend upon `base` and `ghc-prim`.
Further consolidation?
----------------------
Currently GHC ships with at least five UTF-8 implementations:
* the implementation used by GHC in `ghc-boot:GHC.Utils.Encoding`; this
can be used at a number of types including `Addr#`, `ByteArray#`,
`ForeignPtr`, `Ptr`, `ShortByteString`, and `ByteString`. Most of this
can be removed in GHC 9.6+2, when the copies in `base` will become
available to `ghc-boot`.
* the copy of the `ghc-boot` definition now exported by
`base:GHC.Encoding.UTF8`. This can be used at `Addr#`, `Ptr`,
`ByteArray#`, and `ForeignPtr`
* the decoder used by `unpackCStringUtf8#` in `ghc-prim:GHC.CString`;
this is specialised at `Addr#`.
* the codec used by the IO subsystem in `base:GHC.IO.Encoding.UTF8`;
this is specialised at `Addr#` but, unlike the above, supports
recovery in the presence of partial codepoints (since in IO contexts
codepoints may be broken across buffers)
* the implementation provided by the `text` library
This does seem a tad silly. On the other hand, these implementations
*do* materially differ from one another (e.g. in the types they support,
the detail in errors they can report, and the ability to recover from
partial codepoints). Consequently, it's quite unclear that further
consolidate would be worthwhile.
|
|
|
|
|
|
|
|
| |
In preparation for moving the UTF-8 codecs into `base`:
* Move them to GHC.Utils.Encoding.UTF8
* Make names more consistent
* Add some Haddocks
|
|
|
|
|
|
|
|
|
|
|
| |
This patch fixes #21848, by being more careful to update unfoldings
in the type-class specialiser.
See the new Note [Update unfolding after specialisation]
Now that we are being so much more careful about unfoldings,
it turned out that I could dispense with se_interesting, and
all its tricky corners. Hooray. This fixes #21368.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Removed references to driver from GHC.Core.LateCC, GHC.Core.Simplify
namespace and GHC.Core.Opt.Stats.
Also removed services from configuration records.
* Renamed GHC.Core.Opt.Simplify to GHC.Core.Opt.Simplify.Iteration.
* Inlined `simplifyPgm` and renamed `simplifyPgmIO` to `simplifyPgm`
and moved the Simplify driver to GHC.Core.Opt.Simplify.
* Moved `SimplMode` and `FloatEnable` to GHC.Core.Opt.Simplify.Env.
* Added a configuration record `TopEnvConfig` for the `SimplTopEnv` environment
in GHC.Core.Opt.Simplify.Monad.
* Added `SimplifyOpts` and `SimplifyExprOpts`. Provide initialization functions
for those in a new module GHC.Driver.Config.Core.Opt.Simplify.
Also added initialization functions for `SimplMode` to that module.
* Moved `CoreToDo` and friends to a new module GHC.Core.Pipeline.Types
and the counting types and functions (`SimplCount` and `Tick`) to new
module GHC.Core.Opt.Stats.
* Added getter functions for the fields of `SimplMode`. The pedantic bottoms
option and the platform are retrieved from the ArityOpts and RuleOpts and the
getter functions allow us to retrieve values from `SpecEnv` without the
knowledge where the data is stored exactly.
* Moved the coercion optimization options from the top environment to
`SimplMode`. This way the values left in the top environment are those
dealing with monadic functionality, namely logging, IO related stuff and
counting. Added a note "The environments of the Simplify pass".
* Removed `CoreToDo` from GHC.Core.Lint and GHC.CoreToStg.Prep and got rid of
`CoreDoSimplify`. Pass `SimplifyOpts` in the `CoreToDo` type instead.
* Prep work before removing `InteractiveContext` from `HscEnv`.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As pointed out in #21575, it is not sufficient to set withDict to inline
after the typeclass specialiser, because we might inline withDict in one
module and then import it in another, and we run into the same problem.
This means we could still end up with incorrect runtime results because
the typeclass specialiser would assume that distinct typeclass evidence
terms at the same type are equal, when this is not necessarily the case
when using withDict.
Instead, this patch introduces a new magicId, 'nospec', which is only
inlined in CorePrep. We make use of it in the definition of withDict
to ensure that the typeclass specialiser does not common up distinct
typeclass evidence terms.
Fixes #21575
|
|
|
|
|
|
|
|
| |
When growing the Census array ProfHeap previously neglected to
zero the new part of the array. Consequently `freeEra` would attempt to
free random words that often looked suspiciously like pointers.
Fixes #21880.
|
|
|
|
|
|
|
| |
We were failing to stop before running the assembler so the object file
was also created.
Fixes #21869
|
|
|
|
|
|
|
|
| |
Previously we used AC_PATH_PROG which, as noted by #21601, does not
look for tools with a target prefix,
breaking cross-compilation.
Fixes #21601.
|
|
|
|
|
| |
Approved by Core Libraries Committee in
https://github.com/haskell/core-libraries-committee/issues/65#issuecomment-1186275433
|
|
|
|
|
|
|
|
|
| |
While GHC's own aclocal.m4 is generated by the aclocal tool, other
packages' aclocal.m4 are committed in the repository. Previously
`.gitignore` included an entry which covered *any* file named
`aclocal.m4`, which lead to quite some confusion (e.g. see #21740).
Fix this by modifying GHC's `.gitignore` to only cover GHC's own
`aclocal.m4`.
|
|
|
|
|
|
|
|
| |
If the nonmoving gc is enabled and we are using a threaded RTS,
we now try to grab the collector mutex to avoid memInventory and
the collection racing.
Before memInventory was disabled.
|