| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
|
| |
This mirrors the make build system and ensures that we don't end up with
references to the build directory in the final executable.
Fixes #19485.
|
| |
|
|
|
| |
Using .gitatttributes, we don't require users to set git's core.autocrlf
setting to false on Windows to be able to checkout a working tree.
|
| |
|
|
| |
This enables a registerised build for the riscv64 architecture.
|
| |
|
|
|
|
|
|
|
|
| |
This fixes #19484. In detail we:
* Bump the index-state of hackage.
* Require alex-3.2.6, as alex-3.2.5 doesn't build with 9.0.
* Allow Cabal-3.4 as 3.2 doesn't build with ghc 9.0.
* Allow a newer QuickCheck version that accepts the new base version.
* Some code changes to account for Cabal changes.
|
| |
|
|
|
|
|
| |
This is something that's quite important for the correctness of the
incremental build system and doesn't appear to be tested currently; this
test fails on my hashing branch, whereas all of the other (non-perf)
tests pass.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This addresses points (1a) and (1b) of #19165.
- Move mkFailExpr to HsToCore/Utils, as it can be shared
- Desugar incomplete patterns and holes to an empty case,
as in Note [Incompleteness and linearity]
- Enable linear linting of desugarer output
- Mark MultConstructor as broken. It fails Lint, but I'd like to fix this
separately.
Metric Decrease:
T6048
|
| |
|
|
|
|
| |
Previously this test did nothing to prevent GHC from reading .ghci due
to the `-e` arguments. Consequently it could fail due to multiple
reloadings of DynFlags while evaluating .ghci.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Commit 2a94228 dramatically simplified the implementation and improved
the performance of COMPLETE sets while making them applicable in more
scenarios at the same time.
But it turned out that there was a change in semantics that (to me
unexpectedly) broke users' expectations (see #14422): They relied on the
"type signature" of a COMPLETE pragma to restrict the scrutinee types of
a pattern match for which they are applicable.
This patch brings back that filtering, so the semantics is the same as
it was in GHC 9.0.
See the updated Note [Implementation of COMPLETE pragmas].
There are a few testsuite output changes (`completesig13`, `T14422`)
which assert this change.
Co-authored-by: Sebastian Graf <sebastian.graf@kit.edu>
|
| |
|
|
| |
Fixes #19455.
|
| |
|
|
|
|
|
|
| |
markLiveObject is called by GC worker threads and therefore must be
thread-safe. This was a rather egregious oversight which the testsuite
missed.
(cherry picked from commit fe28a062e47bd914a6879f2d01ff268983c075ad)
|
| | |
|
| |
|
|
| |
This was fixed as a result of #19181.
|
| |
|
|
|
|
|
|
|
| |
This produces much more detailed ticky profiles which include names of
constructors.
Related !3340 !2098
Fixes #19403
|
| |
|
|
| |
Part of #17804.
|
| |
|
|
|
|
|
|
|
|
| |
During testing it was observed that quite a few info tables were not
being given locations (due to not being assigned source locations,
because they were not enclosed by a source note). We can at least give
the module name and type for such closures even if no more accurate
source information.
Especially for constructors this helps find them in the STG dumps.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
The `whereFrom` function provides a Haskell interface for using the
information created by `-finfo-table-map`. Given a Haskell value, the
info table address will be passed to the `lookupIPE` function in order
to attempt to find the source location information for that particular closure.
At the moment it's not possible to distinguish the absense of the map
and a failed lookup.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The `-fdistinct-constructor-tables` flag will generate a fresh info
table for the usage of any data constructor. This is useful for
debugging as now by inspecting the info table, you can determine which
usage of a constructor caused that allocation rather than the old
situation where the info table always mapped to the definition site of
the data constructor which is useless.
In conjunction with `-hi` and `-finfo-table-map` this gives a more fine
grained understanding of where constructor allocations arise from in a
program.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This new flag embeds a lookup table from the address of an info table
to information about that info table.
The main interface for consulting the map is the `lookupIPE` C function
> InfoProvEnt * lookupIPE(StgInfoTable *info)
The `InfoProvEnt` has the following structure:
> typedef struct InfoProv_{
> char * table_name;
> char * closure_desc;
> char * ty_desc;
> char * label;
> char * module;
> char * srcloc;
> } InfoProv;
>
> typedef struct InfoProvEnt_ {
> StgInfoTable * info;
> InfoProv prov;
> struct InfoProvEnt_ *link;
> } InfoProvEnt;
The source positions are approximated in a similar way to the source
positions for DWARF debugging information. They are only approximate but
in our experience provide a good enough hint about where the problem
might be. It is therefore recommended to use this flag in conjunction
with `-g<n>` for more accurate locations.
The lookup table is also emitted into the eventlog when it is available
as it is intended to be used with the `-hi` profiling mode.
Using this flag will significantly increase the size of the resulting
object file but only by a factor of 2-3x in our experience.
|
| |
|
|
|
|
|
|
| |
This profiling mode creates bands by the address of the info table for
each closure. This provides a much more fine-grained profiling output
than any of the other profiling modes.
The `-hi` profiling mode does not require a profiling build.
|
| |
|
|
| |
This reverts commit 1c7c6f1afc8e7f7ba5d256780bc9d5bb5f3e7601.
|
| |
|
|
|
|
|
|
|
|
| |
As reported in #19432, the rules governing how `DefaultSignatures` are
typechecked became stricter in GHC 9.0 due to simplified subsumption.
However, this was far from obvious to me after reading the User's Guide section
on `DefaultSignatures`. In this patch, I spruce up the documentation in that
section so that it mentions these nuances.
Resolves #19432.
|
| |
|
|
| |
This applies the fix for #19033 to all the other flavours as well.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
The update of the Outputable instance resulted in a slew of
documentation changes within Notes that used the old syntax.
The most important doc changes are to `Note [Demand notation]`
and the user's guide.
Fixes #19016.
|
| |
|
|
|
| |
Previously a255b4e38918065ac028789872e53239ac30ae1a failed to update the
non-profiling codepath.
|
| |
|
|
|
| |
Previously the profiled flavour transformer failed to add the profiled
ways to the library and RTS ways lists, resulting in link failures.
|
| |
|
|
| |
Thanks @mpickering for finding them!
|
| |
|
|
| |
Avoid returning a lazy panic value when leak indicators are disabled.
|
| |
|
|
| |
($) is INLINE so there is no reason ($!) shouldn't.
|
| |
|
|
|
|
|
|
|
|
| |
This patch exposes three new functions in `GHC.Profiling` which allow
heap profiling to be enabled and disabled dynamically.
1. startHeapProfTimer - Starts heap profiling with the given RTS options
2. stopHeapProfTimer - Stops heap profiling
3. requestHeapCensus - Perform a heap census on the next context
switch, regardless of whether the timer is enabled or not.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The first change makes the array ones use the proper fixed-size types,
which also means that just like before, they can be used without
explicit conversions with the boxed sized types. (Before, it was Int# /
Word# on both sides, now it is fixed sized on both sides).
For the second change, don't use "extend" or "narrow" in some of the
user-facing primops names for conversions.
- Names like `narrowInt32#` are misleading when `Int` is 32-bits.
- Names like `extendInt64#` are flat-out wrong when `Int is
32-bits.
- `narrow{Int,Word}<N>#` however map a type to itself, and so don't
suffer from this problem. They are left as-is.
These changes are batched together because Alex happend to use the array
ops. We can only use released versions of Alex at this time, sadly, and
I don't want to have to have a release thatwon't work for the final GHC
9.2. So by combining these we get all the changes for Alex done at once.
Bump hackage state in a few places, and also make that workflow slightly
easier for the future.
Bump minimum Alex version
Bump Cabal, array, bytestring, containers, text, and binary submodules
|
| |
|
|
|
|
|
| |
Add Data.Type.Ord
Add and update tests
Metric Increase:
MultiLayerModules
|
| | |
|
| |
|
| |
Fixes #17895.
|
| |
|
|
| |
Fixes #17953
|
| |
|
|
| |
AArch64
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously the eventlog infrastructure had a couple of races that could
pop up when using the startEventLog/endEventLog interfaces. In
particular, stopping and then later restarting logging could result in
data preceding the eventlog header, breaking the integrity of the
stream.
To fix this we rework the invariants regarding the eventlog and
generally tighten up the concurrency control surrounding starting and
stopping of logging.
We also fix an unrelated bug, wherein log events from disabled
capabilities could end up never flushed.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Consider (`T18610`):
```hs
f :: Bool -> Int
f x = case (x, x) of
(True, True) -> 1
(False, False) -> 2
(True, False) -> 3 -- Warning: Redundant
```
The third clause will be flagged as redundant. Nevertheless, the
programmer might intend to keep the clause in order to avoid bitrot.
After this patch, the programmer can write
```hs
g :: Bool -> Int
g x = case (x, x) of
(True, True) -> 1
(False, False) -> 2
(True, False) | GHC.Exts.considerAccessible -> 3 -- No warning
```
And won't be bothered any longer. See also `Note [considerAccessible]`
and the updated entries in the user's guide.
Fixes #18610 and #19228.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
While fixing #18610, I noticed that
```hs
f :: Bool -> Int
f x = case (x, x) of
(True, True) -> 1
(False, False) -> 2
```
was *not* detected as exhaustive. I tracked it down to `equateUSDFM`,
where upon merging equality classes of `x` and `y`, we failed to atually
indirect the *representative* `x'` of the equality class of `x` to the
representative `y'` of `y`.
The fixed code is much more naturally and would I should have written in
the first place. I can confirm that the above example now is detected as
exhaustive. The commit that fixes #18610 comes directly after and it has
`f` above as a regression test, so I saw no need to open a ticket or
commit a separate regression test.
|
| |
|
|
|
|
|
| |
If the context is missing it is captured as Nothing, rather than
putting a noLoc in the ParsedSource.
Updates haddock submodule
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Ticket #19360 showed up a terrible bug in the occurrence analyser,
in a situation like this
Rec { f = g
; g = ..f...
{-# RULE g .. = ...f... #-} }
Then f was postInlineUnconditionally, but not in the RULE (which
is simplified first), so we had a RULE mentioning a variable that
was not in scope.
This led me to review (again) the subtle loop-breaker stuff in the
occurrence analyser. The actual changes are few, and are largely
simplifications. I did a /lot/ of comment re-organising though.
There was an unexpected amount of fallout.
* Validation failed when compiling the stage2 compiler with profiling
on. That turned to tickle a second latent bug in the same OccAnal
code (at least I think it was always there), which led me to
simplify still further; see Note [inl_fvs] in GHC.Core.Opt.OccurAnal.
* But that in turn let me to some strange behaviour in CSE when ticks
are in the picture, which I duly fixed. See Note [Dealing with ticks]
in GHC.Core.Opt.CSE.
* Then I got an ASSERT failure in CoreToStg, which again seems to be
a latent bug. See Note [Ticks in applications] in GHC.CoreToStg
* I also made one unforced change: I now simplify the RHS of a RULE in
the same way as the RHS of a stable unfolding. This can allow a
trivial binding to disappear sooner than otherwise, and I don't
think it has any downsides. The change is in
GHC.Core.Opt.Simplify.simplRules.
|
| |
|
|
| |
This is a first step towards #18738.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Ticket #19364 helpfully points out that we do not currently take
advantage of pushing the result type of an application into the
arguments. This makes error messages notably less good.
The fix is rather easy: move the result-type unification step earlier.
It's even a bit more efficient; in the the checking case we now
do one less zonk.
See Note [Unify with expected type before typechecking arguments]
in GHC.Tc.Gen.App
This change generally improves error messages, but it made one worse:
typecheck/should_fail/T16204c. That led me to the realisation that
a good error can be replaced by a less-good one, which provoked
me to change GHC.Tc.Solver.Interact.inertsCanDischarge. It's
explained in the new Note [Combining equalities]
One other refactoring: I discovered that KindEqOrigin didn't need a
Maybe in its type -- a nice simplification.
|
