| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
Hopefully fixes the flaky CI failures we have seen recently.
Co-authored-by: Moritz Angerman <moritz.angermann@gmail.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- fixes #18149 and #14765
dsWhenNoErrs now returns "runtimeError @ty" when disallowed
representation polymorphism is detected, where ty is the type of the
result CoreExpr. "ty" is passed as an additional argument to
dsWhenNoErrs, and is used only in the case of such an error.
The calls to dsWhenNoErrs must now compute the type of the
CoreExpr they are trying to build, so that an error of the right type
can be used in case of a representation polymorphism failure.
|
|
|
|
|
|
|
|
| |
getProgName was used to append the name of the program (e.g. "ghc") to
printed error messages in the Show instance of GhcException. It doesn't
belong here as GHCi and GHC API users may want to override this behavior
by setting a different error handler. So we now call it in the
defaultErrorHandler instead.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
This commit adds the TcRnShadowedName to the TcRnMessage type and it
uses it in GHC.Rename.Utils.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This commit renames the `getErrorMessages` and
`getMessages` function in the parser code to `getPsErrorMessages` and
`getPsMessages`, to avoid import conflicts, as we have already
`getErrorMessages` and `getMessages` defined in `GHC.Types.Error`.
Fixes #19920.
Update haddock submodule
|
|
|
|
|
|
|
| |
This test has worked since 8.10.2 at least but was recently broken and
is now working again after this patch.
Closes #12983
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch converts the runPipeline function to be implemented in terms
of a free monad rather than the previous CompPipeline.
The advantages of this are three-fold:
1. Different parts of the pipeline can return different results, the
limits of runPipeline were being pushed already by !5555, this opens up
futher fine-grainedism of the pipeline.
2. The same mechanism can be extended to build-plan at the module level
so the whole build plan can be expressed in terms of one computation
which can then be treated uniformly.
3. The pipeline monad can now be interpreted in different ways, for
example, you may want to interpret the `TPhase` action into the monad
for your own build system (such as shake). That bit will probably
require a bit more work, but this is a step in the right directin.
There are a few more modules containing useful functions for interacting
with the pipelines.
* GHC.Driver.Pipeline: Functions for building pipelines at a high-level
* GHC.Driver.Pipeline.Execute: Functions for providing the default
interpretation of TPhase, in terms of normal IO.
* GHC.Driver.Pipeline.Phases: The home for TPhase, the typed phase data
type which dictates what the phases are.
* GHC.Driver.Pipeline.Monad: Definitions to do with the TPipelineClass
and MonadUse class.
Hooks consumers may notice the type of the `phaseHook` has got
slightly more restrictive, you can now no longer control the
continuation of the pipeline by returning the next phase to execute but
only override individual phases. If this is a problem then please open
an issue and we will work out a solution.
-------------------------
Metric Decrease:
T4029
-------------------------
|
|
|
|
|
| |
When arguments are 8 *or 16* bits wide, then truncate before/after
and use the 32bit operation.
|
| |
|
| |
|
|
|
|
|
| |
'-x c++' was found to be required on Darwin Clang 11 and 12.
'-std=c++' was found to be needed on Clang 12 but not 11.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
System.Environment.getExecutablePath has some problems:
- Some system-specific implementations throw an exception in some
scenarios, e.g. when the executable file has been deleted
- The Linux implementation succeeds but returns an invalid FilePath
when the file has been deleted.
- The fallback implementation returns argv[0] which is not
necessarily an absolute path, and is subject to manipulation.
- The documentation does not explain any of this.
Breaking the getExecutablePath API or changing its behaviour is not
an appealing direction. So we will provide a new API.
There are two facets to the problem of querying the executable path:
1. Does the platform provide a reliable way to do it? This is
statically known.
2. If so, is there a valid answer, and what is it? This may vary,
even over the runtime of a single process.
Accordingly, the type of the new mechanism is:
Maybe (IO (Maybe FilePath))
This commit implements this mechanism, defining the query action for
FreeBSD, Linux, macOS and Windows.
Fixes: #10957
Fixes: #12377
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In #20070, we noticed that `findRhsArity` copes badly with shadowing.
A simple function like `g_123 x_123 = x_123`, where the labmda binder shadows,
already regressed badly.
Indeed, the whole `arityType` function wasn't thinking about shadowing *at all*.
I rectified that and established the invariant that `ae_join` and `am_sigs`
should always be disjoint. That entails deleting bindings from `ae_join`
whenever we add something to `am_sigs` and vice versa, which would otherwise be
a bug in the making.
That *should* fix (but I don't want to close it) #20070.
|
|
|
|
| |
fixes #19628
|
|
|
|
|
|
| |
This job takes by far the longest time on its own, we now have a NCG.
Once we have fast aarch64 machines, we can consider putting
this one back.
|
|
|
|
| |
This reverts commit a0622459f1d9a7068e81b8a707ffc63e153444f8.
|
| |
|
|
|
|
| |
Fix #20066
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I discovered that GHC.Core.Unify.bindTv was getting arity 2,
rather than 3, in one of my builds. In HEAD it does get the right
arity, but only because CallArity (just) manages to spot it. In my
situation it (just) failed to discover this.
Best to make it robust, which this patch does. See
Note [INLINE pragmas and (>>)] in GHC.Utils.Monad.
There a bunch of other modules that probably should have the same
treatment:
GHC.CmmToAsm.Reg.Linear.State
GHC.Tc.Solver.Monad
GHC.Tc.Solver.Rewrite
GHC.Utils.Monad.State.Lazy
GHC.Utils.Monad.State.Strict
but doing so is not part of this patch
|
|
|
|
|
|
| |
The test case `print036` was marked `broken` by #9046. Issue #9046 is a duplicate of #12449.
However the test case `T12449` contains several test that are similar to those in `print036`.
Hence test case `print036` is redundant and can be deleted.
|
| |
|
|
|
|
| |
We should have fixed clangs mess now.
|
|
|
|
| |
clang's cpp injects spaces prior to #!/.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
by accepting the current state of metrics (and the NCG is new, so this seems
prudent to do), we can require aarch64-linux (ncg) to build without permitting
failure.
Metric Increase:
T13035
T13719
T14697
T1969
T9203
T9872a
T9872b
T9872c
T9872d
T9961
WWRec
haddock.Cabal
haddock.base
parsing001
|
|
|
|
| |
Signed-off-by: Emily Martins <emily.flakeheart@gmail.com>
|
|
|
|
|
|
|
| |
Fixes #20042
Signed-off-by: Emily Martins <emily.flakeheart@gmail.com>
Signed-off-by: Hécate Moonlight <hecate@glitchbra.in>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Use DiagOpts for diagnostic options instead of directly querying
DynFlags (#17957).
Surprising performance improvements on CI:
T4801(normal) ghc/alloc 313236344.0 306515216.0 -2.1% GOOD
T9961(normal) ghc/alloc 384502736.0 380584384.0 -1.0% GOOD
ManyAlternatives(normal) ghc/alloc 797356128.0 786644928.0 -1.3%
ManyConstructors(normal) ghc/alloc 4389732432.0 4317740880.0 -1.6%
T783(normal) ghc/alloc 408142680.0 402812176.0 -1.3%
Metric Decrease:
T4801
T9961
T783
ManyAlternatives
ManyConstructors
Bump haddock submodule
|
| |
|
| |
|
|
|
|
| |
Avoid an other regression.
|
|
|
|
| |
Part way to #20013
|
|
|
|
| |
Fixes #14380, #19997
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In #19050, we identified several ways in which we could make more illegal
states irrepresentable. This patch introduces a few representation changes
around `Demand` and `Card` with a better and earlier-failing API exported
through pattern synonyms. Specifically,
1. The old enum definition of `Card` led to severely bloated code of operations
on it. I switched to a bit vector representation; much nicer overall IMO.
See Note [Bit vector representation for Card].
Most of the gripes with the old representation were related to where which kind
of `Card` was allowed and the fact that it doesn't make sense for an absent or
bottoming demand to carry a `SubDemand` that describes an evaluation context
that is never realised.
2. So I refactored the `Demand` representation so that it has two new data
constructors for `AbsDmd` and `BotDmd`. The old `(:*)` data constructor
becomes a pattern synonym which expands absent demands as needed, so that
it still forms a complete match and a versatile builder. The new `Demand`
data constructor now carries a `CardNonAbs` and only occurs in a very limited
number of internal call sites.
3. Wherever a full-blown `Card` might end up in a `CardNonAbs` field (like that
of `D` or `Call`), I assert the consistency. When the smart builder of `(:*)`
is called with an absent `Card`, I assert that the `SubDemand` is the same
that we would expand to in the matcher.
4. `Poly` now takes a `CardNonOnce` and encodes the previously noticed invariant
that we never produce `Poly C_11` or `Poly C_01`. I made sure that we never
construct a `Poly` with `C_11` or `C_01`.
Fixes #19050.
We lose a tiny bit of anal perf overall, probably because the new `Demand`
definition can't be unboxed. The biggest loser is WWRec, where allocations go
from 16MB to 26MB in DmdAnal, making up for a total increase of (merely) 1.6%.
It's all within acceptance thresholds.
There are even two ghc/alloc metric decreases. T11545 decreases by *67%*!
Metric Decrease:
T11545
T18304
|
|
|
|
|
|
| |
This is a follow-up to #19992, which fixes the type and strictness signature
for `fork#`. The `forkOn#` primop also needs analogous changes, which this
patch accomplishes.
|
|
|
|
|
|
|
|
|
|
|
| |
This commit tries to untangle the zoo of diagnostic-related functions
in `Tc.Utils.Monad` so that we can have the interfaces mentions only
`TcRnMessage`s while we push the creation of these messages upstream.
It also ports TcRnMessage diagnostics to use the new API, in particular
this commit switch to use TcRnMessage in the external interfaces
of the diagnostic functions, and port the old SDoc to be wrapped
into TcRnUnknownMessage.
|