| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
| |
There is no need to run arity analysis and what not if we are not in a
Simplifier phase that eta-expands or if we don't want to eta-expand the
expression in the first place.
Purely a refactoring with the goal of improving compiler perf.
|
| |
|
| |
|
|
|
|
|
|
|
| |
We should not panic in `add_demands` (now `set_lam_dmds`), because that code
path is legimitely taken for OPAQUE PAP bindings, as in T22997.
Fixes #22997.
|
|
|
|
|
|
|
|
|
| |
Previously the solver failed with an unhelpful "solver reached too may iterations" error.
With the fix for #21909 in place we no longer have the possibility of generating such an error if we have `-fconstraint-solver-iteration` > `-fgivens-fuel > `-fwanteds-fuel`. This is true by default, and the said fix also gives programmers a knob to control how hard the solver should try before giving up.
This commit adds:
* Reference to ticket #19627 in the Note [Expanding Recursive Superclasses and ExpansionFuel]
* Test `typecheck/should_fail/T19627.hs` for regression purposes
|
|
|
|
|
|
|
|
| |
This patch adds temporary subdirectories to the list of
paths do clean up at the end of the GHC session. This
fixes warnings about non-empty temporary directories.
Fixes #22952
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
!9193 pointed out that ghcDebugAssertions was supposed to be a predicate
on the stage of the built compiler, but in practice it was a predicate
on the stage of the compiler used to build. Unfortunately, while it
fixed that issue for ghcDebugAssertions, it documented every other
similar option as behaving the same way when in fact they all used the
old behavior.
The new behavior of ghcDebugAssertions seems more intuitive, so this
commit changes the interpretation of every other option to match. It
also improves the enableProfiledGhc and debugGhc flavour transformers by
making them more selective about which stages in which they build
additional library/RTS ways.
|
| |
|
|
|
|
|
| |
The number of distinct arguments passed to GarbageCollect was getting a
bit out of hand.
|
|
|
|
| |
Finalization order is different under the nonmoving collector.
|
| |
|
|
|
|
| |
This should be INLINE_HEADER lest we get unused declaration warnings.
|
|
|
|
|
| |
To reflect the fact that these are to do with the nonmoving collector,
now since they are exposed no longer static.
|
|
|
|
|
| |
It doesn't make sense to run these in multiple ways as they merely test
whether `-threaded`/`-single-threaded` flags.
|
| |
|
| |
|
| |
|
|
|
|
| |
For using GHC bootstrapping to validate the non-moving GC.
|
| |
|
| |
|
| |
|
|
|
|
|
| |
This makes it a bit easier to add instrumentation on this spinlock
while debugging.
|
|
|
|
|
|
| |
When the nonmoving GC is in use we do not call `checkUnload` (since we
don't unload code) and therefore should not call `prepareUnloadCheck`,
lest we run into assertions.
|
|
|
|
|
|
|
| |
The nonmoving collector does not use `oldest_gen->blocks` to track its
block list. However, it nevertheless updates `oldest_gen->n_blocks` to
ensure that its size is accounted for by the storage manager.
Consequently, we must not attempt to assert consistency between the two.
|
|
|
|
|
| |
Some references to Note [Deadlock detection under the non-moving
collector] were missing an article.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The current segments are conceptually owned by the mutator, not the
collector. Consequently, it was quite tricky to prove that the mutator
would not race with the collect due to this shared state. It turns out
that such races are possible: when resizing the current segment array
we may concurrently try to take a heap census. This will attempt to walk
the current segment array, causing a data race.
Fix this by moving the current segment array into `Capability`, where it
belongs.
Fixes #22926.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Here we significantly improve the bound on sync phase pause times by
imposing a limit on the amount of work that we can perform during the
sync. If we find that we have exceeded our marking budget then we allow
the mutators to resume, return to concurrent marking, and try
synchronizing again later.
Fixes #22929.
|
|
|
|
|
| |
Previously we left various segment link pointers dangling. None of this
wrong per se, but it did make it harder than necessary to debug.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
This fixes the selector optimisation, adding a few write barriers which
are necessary for soundness. See the inline comments for details.
Fixes #22930.
|
|
|
|
|
|
|
|
|
| |
Previously `storageAddCapabilities` (called by `setNumCapabilities`) would
clobber the update remembered sets of existing capabilities when
increasing the capability count. Fix this by only initializing the
update remembered sets of the newly-created capabilities.
Fixes #22927.
|
|
|
|
|
| |
We must conservatively assume that new closures are reachable since we
are not guaranteed to mark such blocks.
|
| |
|
|
|
|
|
| |
Previously we only updated the state of the segment at the head of each
allocator's filled list.
|
| |
|
|
|
|
|
| |
Assert that entries in the nonmoving generation's generational
remembered set (a.k.a. mutable list) live in nonmoving generation.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes an interaction between aging and weak pointer handling which
prevented the finalization of some weak pointers. In particular, weak
pointers could have their keys incorrectly marked by the preparatory
collector, preventing their finalization by the subsequent concurrent
collection.
While in the area, we also significantly improve the assertions
regarding weak pointers.
Fixes #22327.
|
|
|
|
|
|
|
|
| |
Previously the write barrier of resizeSmallArray# incorrectly handled
resizing of zero-sized arrays, pushing an invalid pointer to the update
remembered set.
Fixes #22931.
|
| |
|
| |
|
|
|
|
| |
This makes the intent of this implementation a bit clearer.
|
| |
|
| |
|
| |
|