| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
Now #21563 is fixed we can properly enable `-dlint` in CI rather than a
subset of the flags.
|
| |
|
|
|
|
|
|
| |
We originally planned to remove the flag in 9.4 but there's actually no
great rush to do so and it's probably less confusing (forever) to keep
the message around suggesting an explicit profiling option.
Fixes #21545
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes two bugs which were adding dependencies on alex/happy when
building from a source dist.
* When we try to pass `--with-alex` and `--with-happy` to cabal when
configuring but the builders are not set. This is fixed by making them
optional.
* When we configure, cabal requires alex/happy because of the
build-tool-depends fields. These are now made optional with a cabal
flag (build-tool-depends) for compiler/hpc-bin/genprimopcode.
Fixes #21627
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a large collection of changes all relating to eta
reduction, originally triggered by #18993, but there followed
a long saga.
Specifics:
* Move state-hack stuff from GHC.Types.Id (where it never belonged)
to GHC.Core.Opt.Arity (which seems much more appropriate).
* Add a crucial mkCast in the Cast case of
GHC.Core.Opt.Arity.eta_expand; helps with T18223
* Add clarifying notes about eta-reducing to PAPs.
See Note [Do not eta reduce PAPs]
* I moved tryEtaReduce from GHC.Core.Utils to GHC.Core.Opt.Arity,
where it properly belongs. See Note [Eta reduce PAPs]
* In GHC.Core.Opt.Simplify.Utils.tryEtaExpandRhs, pull out the code for
when eta-expansion is wanted, to make wantEtaExpansion, and all that
same function in GHC.Core.Opt.Simplify.simplStableUnfolding. It was
previously inconsistent, but it's doing the same thing.
* I did a substantial refactor of ArityType; see Note [ArityType].
This allowed me to do away with the somewhat mysterious takeOneShots;
more generally it allows arityType to describe the function, leaving
its clients to decide how to use that information.
I made ArityType abstract, so that clients have to use functions
to access it.
* Make GHC.Core.Opt.Simplify.Utils.rebuildLam (was stupidly called
mkLam before) aware of the floats that the simplifier builds up, so
that it can still do eta-reduction even if there are some floats.
(Previously that would not happen.) That means passing the floats
to rebuildLam, and an extra check when eta-reducting (etaFloatOk).
* In GHC.Core.Opt.Simplify.Utils.tryEtaExpandRhs, make use of call-info
in the idDemandInfo of the binder, as well as the CallArity info. The
occurrence analyser did this but we were failing to take advantage here.
In the end I moved the heavy lifting to GHC.Core.Opt.Arity.findRhsArity;
see Note [Combining arityType with demand info], and functions
idDemandOneShots and combineWithDemandOneShots.
(These changes partly drove my refactoring of ArityType.)
* In GHC.Core.Opt.Arity.findRhsArity
* I'm now taking account of the demand on the binder to give
extra one-shot info. E.g. if the fn is always called with two
args, we can give better one-shot info on the binders
than if we just look at the RHS.
* Don't do any fixpointing in the non-recursive
case -- simple short cut.
* Trim arity inside the loop. See Note [Trim arity inside the loop]
* Make SimpleOpt respect the eta-reduction flag
(Some associated refactoring here.)
* I made the CallCtxt which the Simplifier uses distinguish between
recursive and non-recursive right-hand sides.
data CallCtxt = ... | RhsCtxt RecFlag | ...
It affects only one thing:
- We call an RHS context interesting only if it is non-recursive
see Note [RHS of lets] in GHC.Core.Unfold
* Remove eta-reduction in GHC.CoreToStg.Prep, a welcome simplification.
See Note [No eta reduction needed in rhsToBody] in GHC.CoreToStg.Prep.
Other incidental changes
* Fix a fairly long-standing outright bug in the ApplyToVal case of
GHC.Core.Opt.Simplify.mkDupableContWithDmds. I was failing to take the
tail of 'dmds' in the recursive call, which meant the demands were All
Wrong. I have no idea why this has not caused problems before now.
* Delete dead function GHC.Core.Opt.Simplify.Utils.contIsRhsOrArg
Metrics: compile_time/bytes allocated
Test Metric Baseline New value Change
---------------------------------------------------------------------------------------
MultiLayerModulesTH_OneShot(normal) ghc/alloc 2,743,297,692 2,619,762,992 -4.5% GOOD
T18223(normal) ghc/alloc 1,103,161,360 972,415,992 -11.9% GOOD
T3064(normal) ghc/alloc 201,222,500 184,085,360 -8.5% GOOD
T8095(normal) ghc/alloc 3,216,292,528 3,254,416,960 +1.2%
T9630(normal) ghc/alloc 1,514,131,032 1,557,719,312 +2.9% BAD
parsing001(normal) ghc/alloc 530,409,812 525,077,696 -1.0%
geo. mean -0.1%
Nofib:
Program Size Allocs Runtime Elapsed TotalMem
--------------------------------------------------------------------------------
banner +0.0% +0.4% -8.9% -8.7% 0.0%
exact-reals +0.0% -7.4% -36.3% -37.4% 0.0%
fannkuch-redux +0.0% -0.1% -1.0% -1.0% 0.0%
fft2 -0.1% -0.2% -17.8% -19.2% 0.0%
fluid +0.0% -1.3% -2.1% -2.1% 0.0%
gg -0.0% +2.2% -0.2% -0.1% 0.0%
spectral-norm +0.1% -0.2% 0.0% 0.0% 0.0%
tak +0.0% -0.3% -9.8% -9.8% 0.0%
x2n1 +0.0% -0.2% -3.2% -3.2% 0.0%
--------------------------------------------------------------------------------
Min -3.5% -7.4% -58.7% -59.9% 0.0%
Max +0.1% +2.2% +32.9% +32.9% 0.0%
Geometric Mean -0.0% -0.1% -14.2% -14.8% -0.0%
Metric Decrease:
MultiLayerModulesTH_OneShot
T18223
T3064
T15185
T14766
Metric Increase:
T9630
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch concerns #20155, part (1)
The general idea is that since primops have curried bindings
(currently in PrimOpWrappers.hs) we don't need to eta-expand
them. But we /do/ need to eta-expand the levity-polymorphic ones,
because they /don't/ have bindings.
This patch makes a start in that direction, by identifying the
levity-polymophic primops in the PrimOpId IdDetails constructor.
For the moment, I'm still eta-expanding all primops (by saying
that hasNoBinding returns True for all primops), because of the
bug reported in #20155. But I hope that before long we can
tidy that up too, and remove the TEMPORARILY stuff in hasNoBinding.
|
| | |
|
| |
|
|
|
| |
This avoids a fixpoint iteration for the common case of
non-recursive bindings.
|
| |
|
|
|
| |
Sometimes there are very large casts, and coercionRKind
can be slow.
|
| |
|
|
|
|
|
| |
We want to be able to eta-reduce
\x y. ((f x) |> co) y
by pushing 'co' inwards. A very small change accommodates this
See Note [Eta reduction with casted function]
|
| | |
|
| | |
|
| |
|
|
|
|
| |
This is preliminary work for JavaScript support. It's better to put the
code handling the desugaring of Prim, C and JavaScript declarations into
separate modules.
|
| |
|
|
|
|
|
|
|
| |
Due to the vageries of bash, you have to explicitly handle the failure
and exit when in a function.
This failed to exit promptly when !8247 was failing.
See #21358 for the general issue
|
| |
|
|
|
|
|
| |
It was previously disabled because of:
- a confusion about "SRT inlining" (see removed comment in this commit)
- a linker bug (overflow) in the handling of ARM64_RELOC_SUBTRACTOR
relocation: fixed by a previous commit.
|
| |
|
|
|
|
|
|
|
| |
- reordered the 3 SRT implementation cases from the most general to the
most specific one:
USE_SRT_POINTER -> USE_SRT_OFFSET -> USE_INLINE_SRT_FIELD
- added requirements for each
- found and documented a confusion about "SRT inlining" not supported
with MachO. (It is fixed in the following commit)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ARM64_RELOC_SUBTRACTOR relocations are paired with an
AMR64_RELOC_UNSIGNED relocation to implement: addend + sym1 - sym2
The linker was doing it in two steps, basically:
*addend <- *addend - sym2
*addend <- *addend + sym1
The first operation was likely to overflow. For example when the
relocation target was 32-bit and both sym1/sym2 were 64-bit addresses.
With the small memory model, (sym1-sym2) would fit in 32 bits but
(*addend-sym2) may not.
Now the linker does it in one step:
*addend <- *addend + sym1 - sym2
|
| |
|
|
| |
it is still re-exported from GHC.Exts
|
| | |
|
| |
|
|
| |
Fixes #21659
|
| |
|
|
|
|
|
|
|
| |
The theory is that on windows there is some difference in the
environment between pipelines on master and merge requests which affects
all tests equally but because T16875 barely allocates anything it is the
test which is affected the most.
See #21557
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Commit acb188e0 introduced a regression in the computation of free
variables in mdo statements, as the logic in
GHC.Rename.Expr.segmentRecStmts was slightly different depending on
whether the recursive do block corresponded to an mdo statement or
a rec statment.
This patch restores the previous computation for mdo blocks.
Fixes #21654
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This moves handling of the magic 'withDict' function from the desugarer
to the typechecker. Details in Note [withDict].
I've extracted a part of T16646Fail to a separate file T16646Fail2,
because the new error in 'reify' hides the errors from 'f' and 'g'.
WithDict now works with casts, this fixes #21328.
Part of #19915
|
| |
|
|
|
|
| |
fix #21658
fix #21657
fix #21657
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The function breakTyVarCycle_maybe has been installed
in a dark corner of GHC to catch some gremlins (a.k.a.
occurs-check failures) who lurk
there. But it previously only caught gremlins of the
form (a ~ ... F a ...), where some of our intrepid users
have spawned gremlins of the form (G a ~ ... F (G a) ...).
This commit improves breakTyVarCycle_maybe (and renames
it to breakTyEqCycle_maybe) to catch the new gremlins.
Happily, the change is remarkably small.
The gory details are in Note [Type equality cycles].
Test cases: typecheck/should_compile/{T21515,T21473}.
|
| |
|
|
|
| |
This patch adds several tests relating to the eta-expansion of
data constructors, including UnliftedNewtypes and DataTypeContexts.
|
| | |
|
| |
|
|
| |
We want `DynFlags` only mentioned in `GHC.Driver`.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
executablePath support for NetBSD was added in
a172be07e3dce758a2325104a3a37fc8b1d20c9c, but the test was not
updated.
Update the test so that it works for NetBSD. This requires handling
some quirks:
- The result of getExecutablePath could include "./" segments.
Therefore use System.FilePath.equalFilePath to compare paths.
- The sysctl(2) call returns the original executable name even after
it was deleted. Add `canQueryAfterDelete :: [FilePath]` and
adjust expectations for the post-delete query accordingly.
Also add a note to the `executablePath` haddock to advise that
NetBSD behaves differently from other OSes when the file has been
deleted.
Also accept a decrease in memory usage for T16875. On Windows, the
metric is -2.2% of baseline, just outside the allowed ±2%. I don't
see how this commit could have influenced this metric, so I suppose
it's something in the CI environment.
Metric Decrease:
T16875
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The executablePath test strips the file extension (if any) when
comparing the query result with the expected value. This is to
handle platforms where GHC adds a file extension to the output
program file (e.g. .exe on Windows).
After the initial check, the file gets deleted (if supported).
However, it tries to delete the *stripped* filename, which is
incorrect. The test currently passes only because Windows does not
allow deleting the program while any process created from it is
alive.
Make the test program correct in general by deleting the
*non-stripped* executable filename.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The functions `pushCoValArg` and `pushCoercionIntoLambda` could
introduce bad representation-polymorphism. Example:
type RR :: RuntimeRep
type family RR where { RR = IntRep }
type F :: TYPE RR
type family F where { F = Int# }
co = GRefl F (TYPE RR[0])
:: (F :: TYPE RR)
~# (F |> TYPE RR[0] :: TYPE IntRep)
f :: F -> ()
`pushCoValArg` would transform the unproblematic application
(f |> (co -> <()>)) (arg :: F |> TYPE RR[0])
into an application in which the argument does not have a fixed
`RuntimeRep`:
f ((arg |> sym co) :: (F :: TYPE RR))
|
| |
|
|
| |
Progress towards #17957
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch typechecks record updates by desugaring them inside
the typechecker using the HsExpansion mechanism, and then typechecking
this desugared result.
Example:
data T p q = T1 { x :: Int, y :: Bool, z :: Char }
| T2 { v :: Char }
| T3 { x :: Int }
| T4 { p :: Float, y :: Bool, x :: Int }
| T5
The record update `e { x=e1, y=e2 }` desugars as follows
e { x=e1, y=e2 }
===>
let { x' = e1; y' = e2 } in
case e of
T1 _ _ z -> T1 x' y' z
T4 p _ _ -> T4 p y' x'
The desugared expression is put into an HsExpansion, and we typecheck
that.
The full details are given in Note [Record Updates] in GHC.Tc.Gen.Expr.
Fixes #2595 #3632 #10808 #10856 #16501 #18311 #18802 #21158 #21289
Updates haddock submodule
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The simple optimiser would sometimes fail to
beta-reduce a lambda when there were casts
in between the lambda and its arguments.
This can cause problems because we rely on
representation-polymorphic lambdas getting
beta-reduced away (for example, those
that arise from newtype constructors with
representation-polymorphic arguments, with
UnliftedNewtypes).
|
| |
|
|
|
| |
Metric Decrease:
T16875
|
| |
|
|
|
|
|
| |
The conditional in hadrian/bindist/Makefile depended on the target OS,
but it makes more sense to use whether we are using a relocatable build.
(Currently this only gets set to true on Windows, but this ensures
that the logic stays correctly coupled.)
|
| |
|
|
|
|
|
|
|
|
|
| |
-haddock on GHC < 9.0 is quite fragile and can result in obtuse parse errors
when it encounters invalid haddock syntax.
This has started to affect users since 297156e0b8053a28a860e7a18e1816207a59547b
enabled -haddock by default on many flavours.
Furthermore, since we don't test bootstrapping with 8.10 on CI, this problem
managed to slip throught the cracks.
|
| |
|
|
|
|
| |
We use the 64bit shifts only on 64bit platforms. But we
compile the code always so compiling it on 32bit caused a
lint error. So use Word64 instead.
|
| |
|
|
| |
This should get rid of most, if not all "Overlong lists" errors and fix #20016
|
| |
|
|
|
|
|
| |
With all the recent W^X fixes in the loader this workaround is not
necessary any longer. I verified that the only tests failing for me on
OpenBSD 7.1-current are the same (libc++ related) before and after
this commit (with --fast).
|
| |
|
|
|
|
| |
`install.mk` is already included by `config.mk`. Moreover, `install.mk`
depends upon `config.mk` to set `RelocatableBuild`, making this first
include incorrect.
|
