| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
|
| |
The minimum required GHC version for bootstrapping is 8.6, so we can
get rid of some unneeded `#if `__GLASGOW_HASKELL__` CPP guards, as
well as one `MIN_VERSION_ghc_prim(0,5,3)` guard (since GHC 8.6 bundles
`ghc-prim-0.5.3`).
|
| |
|
|
|
| |
The `Ix` class seems rather orthogonal to its original home in
`GHC.Arr`.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Introduces a new flag `-fmax-pmcheck-deltas` to achieve that. Deprecates
the old `-fmax-pmcheck-iter` mechanism in favor of this new flag.
From the user's guide:
Pattern match checking can be exponential in some cases. This limit makes sure
we scale polynomially in the number of patterns, by forgetting refined
information gained from a partially successful match. For example, when
matching `x` against `Just 4`, we split each incoming matching model into two
sub-models: One where `x` is not `Nothing` and one where `x` is `Just y` but
`y` is not `4`. When the number of incoming models exceeds the limit, we
continue checking the next clause with the original, unrefined model.
This also retires the incredibly hard to understand "maximum number of
refinements" mechanism, because the current mechanism is more general
and should catch the same exponential cases like PrelRules at the same
time.
-------------------------
Metric Decrease:
T11822
-------------------------
|
| |
|
|
|
| |
It doesn't need it, and it shouldn't need it or else multi-target will
break.
|
| |
|
|
|
|
| |
Enabling both DeriveAnyClass and GeneralizedNewtypeDeriving can cause
a warning when no explicit deriving strategy is in use. This change adds
an enable/suppress flag for it.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit adds three new files
1. A hie.yaml file to the project root which specifies to IDEs how to
set up the correct environment for loading GHC. This currently
specifies to call the `./hadrian/hie-bios` script.
2. A `hie.yaml` file for the hadrian subcomponent, which uses the
`cabal` cradle type.
2. The `./hadrian/hie-bios` script which supplies the correct arguments
for an IDE to start a session.
With these two files it is possible to run
```
ghcide compiler/
```
and successfully load all the modules for use in the IDE.
or
```
ghcide --cwd hadrian/ src/
```
to test loading all of Hadrian's modules.
Closes #17194
|
| |
|
|
|
|
|
|
| |
The old test was wrong at least for gcc and the value -2287728808L.
It also relied on implementation defined behaviour (right shift
on a negative value), which might or might not be ok.
Either way it's now a simple comparison which will always work.
|
| |
|
|
| |
Due to #16555.
|
| | |
|
| |
|
|
|
| |
This bumps the CI Docker images to
ghc/ci-images@990c5217d1d0e03aea415f951afbc3b1a89240c6.
|
| |
|
|
| |
Fixes #17181.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
D3673 experienced reduce/reduce conflicts when trying to use
opt_instance for associated data families.
That was probably because the author tried to use it for
Haskell98-syntax without also applying it to GADT-syntax, which actually
leads to a reduce/reduce conflict. Consider the following state:
```
data . T = T
data . T where T :: T
```
The parser must decide at this point whether or not to reduce an empty
`opt_instance`. But doing so would also commit to either
Haskell98 or GADT syntax! Good thing we also accept an optional
"instance" for GADT syntax, so the `opt_instance` is there in both
productions and there's no reduce/reduce conflict anymore.
Also no need to inline `opt_instance`, how it used to be.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit adds -haddock option to Hadrian-based build system.
To enable :doc command on GHCi, core libraries must be compiled
with -haddock option.
Especially, the `-haddock` option is essential for a release build.
Assuming current GitLab CI condition (.gitlab-ci.yml),
I add -haddock option to the default flavour only.
This has already been done for Make-based build system.
Please see #16415.
|
| | |
|
| |
|
|
|
| |
Add a new optional failure handling for upsweep which continues
the compilation on other modules if any of them has errors.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently, if you change these ^ flavour parameters, rebuilding is not
triggered, since `programContext` doesn't set up a dependency on
those values.
Exposing these values via an oracle does set the dependency and
properly triggers a rebuild of binaries.
Several attempts to factor out these actions ended up in cyclic
dependency here or there. I'm not absolutely happy with this variant
either, but at least it works.
====
Issue repro:
In UserSettings.hs:
```
dbgDynamic = defaultFlavour { name = "dbg-dynamic"
, dynamicGhcPrograms = pure True,
... }
dbgStatic = defaultFlavour { name = "dbg-static"
, dynamicGhcPrograms = pure False
... }
```
Then in console:
```
$ hadrian/build.sh -j --flavour=dbg-dynamic
... does the build
$ hadrian/build.sh -j --flavour=dbg-static
... does nothing, considers binaries up to date
```
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
Metric Increase:
haddock.base
T4029
|
| |
|
|
|
|
| |
This commit only fixes links and markdown syntax.
[skip ci]
|
| | |
|
| | |
|
| |
|
|
| |
[ci skip]
|
| |
|
|
|
| |
The 'cp' field really is only used when type==posTypeFresh so it's more
space efficient to have it in the nextPos union.
|
| | |
|
| | |
|
| |
|
|
|
| |
This finally moves the newly generalised heap traversal code from the
retainer profiler into it's own file.
|
| |
|
|
|
| |
A lot of these includes are presumably leftovers from when the retainer
profiler still did it's own heap profiling.
|
| |
|
|
|
|
| |
Turns out some genius disabled warnings for RetainerProfile.c in the build
system. That would have been good to know about five silent type mismatch
crashes ago.. :)
|
| | |
|
| |
|
|
|
|
|
|
|
| |
Currently it is necessary for user code to expend at least one extra bit in
the closure header just to know whether visit() should return true or
false, to indicate if children should be traversed.
The generic traversal code already has this information in the visited bit
so simply pass it to the visit callback.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There's simply no need anymore for this whole business. Instead of
individually traversing roots in retainRoot() we just push them all onto
the stack and traverse everything in one go.
This feature was not really used anyways. There is an
`ASSERT(isEmptyWorkStack(ts))` at the top of retainRoot() which means there
really can't ever have been any chunks at the toplevel.
The only place where this was probably used is in traversePushStack but
only way back when we were still using explicit recursion on the
C callstack.
Since the code was changed to use an explicit traversal-stack these
stack-chunks can never escape one call to traversePushStack anymore. See
commit 5f1d949ab9 ("Remove explicit recursion in retainer profiling")
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
STATIC_INLINE already does what the code wanted here, no need to duplicate
the functionality here.
|
| |
|
|
|
|
| |
These invariants don't seem to make any sense in the current code. The
text talks about c_child_r as if it were an StgClosure, for which RSET()
would make sense, but it's a retainer aka 'CostCentreStack*'.
|
| |
|
|
|
| |
A lot of comments and strings are still talking about old names, fix
that.
|
| |
|
|
|
|
|
|
|
|
| |
Keeping track of the maximum stack seems like a good idea in all
configurations. The associated ASSERTs only materialize in debug mode but
having the statistic is nice.
To make the debug code less prone to bitrotting I introduce a function
'debug()' which doesn't actually print by default and is #define'd away
only when the standard DEBUG define is off.
|
| |
|
|
|
| |
This gets all remaining functions in-line with the new 'traverse' prefix
and module name.
|
| |
|
|
|
|
|
| |
Commit dbef766ce7 ("Profiling cleanup.") made this debug code obsolete by
removing the 'cost' function without a replacement. As best I can tell the
retainer profiler used to do some heap census too and this debug code was
mainly concerned with that.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
In the old code when DEBUG_RETAINER was set, FIRST_APPROACH is
implied. However ProfHeap.c now depends on printRetainerSetShort which is
only available with SECOND_APPROACH. This is because with FIRST_APPROACH
retainerProfile() will free all retainer sets before returning so by the
time ProfHeap calls dumpCensus the retainer set pointers are segfaulty.
Since all of this debugging code obviously hasn't been compiled in ages
anyways I'm taking the liberty of just removing it.
Remember guys: Dead code is a liability not an asset :)
|
| | |
|
