| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch fixes some abundant reboxing of `DynFlags` in
`GHC.HsToCore.Match.Literal.warnAboutOverflowedLit` with a justifiable hack.
See the new `Note [Turn LP(A) into LP(M) in signatures]` and the new regression
test `T19407`.
There is a +4% ghc/alloc metric increase in T12545. The baseline is 1.7GB, this
patch uses 1.76GB. But if I pass `-v` then suddenly the baseline takes 1.8GB, this
patch 1.78GB. So it's actually an improvement! It appears that this patch is
somehow a bit more strict. In fact, in other jobs the same metric decreases.
Tracked as #19801.
Metric Increase:
T12545
Metric Decrease:
T12545
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
before:
> /home/matt/Projects/persistent/persistent/Database/Persist/ImplicitIdDef.hs:1:8: error:
> File name does not match module name:
> Saw: ‘A.B.Module’
> Expected: ‘A.B.Motule’
> |
> 1 | module A.B.Motule
> | ^^^^^^^^^^>
after:
> /home/matt/Projects/persistent/persistent/Database/Persist/ImplicitIdDef.hs:1:8: error:
> File name does not match module name:
> Saw: ‘A.B.Module’
> Expected: ‘A.B.Motule’
> |
> 1 | module A.B.Motule
> | ^^^^^^^^^^>
|
| |
|
|
|
|
| |
Fixes #8144
|
|
|
|
|
|
|
|
|
|
|
| |
It is possible that the type variables bound by a class header will map to
something different in the typechecker in the presence of
`StandaloneKindSignatures`. `tcClassDecl2` was not aware of this, however,
leading to #19738. To fix it, in `tcTyClDecls` we map each class `TcTyCon` to
its `tcTyConScopedTyVars` as a `ClassScopedTVEnv`. We then plumb that
`ClassScopedTVEnv` to `tcClassDecl2` where it can be used.
Fixes #19738.
|
|
|
|
|
| |
This fixes an oversight in the implementation of `extract_lctxt` which
was introduced in commit ce85cffc. Fixes #19759.
|
|
|
|
|
|
|
|
| |
Doing so is important to maintain invariants (EQ3) and (EQ4) from
`Note [Respecting definitional equality]` in `GHC.Core.TyCo.Rep`. For the
details, see the new `Note [Using coreView in mk_cast_ty]`.
Fixes #19742.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This gives a more precise type signature to `magicDict` as proposed in #16646.
In addition, this replaces the constant-folding rule for `magicDict` in
`GHC.Core.Opt.ConstantFold` with a special case in the desugarer in
`GHC.HsToCore.Expr.dsHsWrapped`. I have also renamed `magicDict` to `withDict`
in light of the discussion in
https://mail.haskell.org/pipermail/ghc-devs/2021-April/019833.html.
All of this has the following benefits:
* `withDict` is now more type safe than before. Moreover, if a user applies
`withDict` at an incorrect type, the special-casing in `dsHsWrapped` will
now throw an error message indicating what the user did incorrectly.
* `withDict` can now work with classes that have multiple type arguments, such
as `Typeable @k a`. This means that `Data.Typeable.Internal.withTypeable` can
now be implemented in terms of `withDict`.
* Since the special-casing for `withDict` no longer needs to match on the
structure of the expression passed as an argument to `withDict`, it no
longer cares about the presence or absence of `Tick`s. In effect, this
obsoletes the fix for #19667.
The new `T16646` test case demonstrates the new version of `withDict` in
action, both in terms of `base` functions defined in terms of `withDict`
as well as in terms of functions from the `reflection` and `singletons`
libraries. The `T16646Fail` test case demonstrates the error message that GHC
throws when `withDict` is applied incorrectly.
This fixes #16646. By adding more tests for `withDict`, this also
fixes #19673 as a side effect.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit adds GhcMessage and ancillary (PsMessage, TcRnMessage, ..)
types.
These types will be expanded to represent more errors generated
by different subsystems within GHC. Right now, they are underused,
but more will come in the glorious future.
See
https://gitlab.haskell.org/ghc/ghc/-/wikis/Errors-as-(structured)-values
for a design overview.
Along the way, lots of other things had to happen:
* Adds Semigroup and Monoid instance for Bag
* Fixes #19746 by parsing OPTIONS_GHC pragmas into Located Strings.
See GHC.Parser.Header.toArgs (moved from GHC.Utils.Misc, where it
didn't belong anyway).
* Addresses (but does not completely fix) #19709, now reporting
desugarer warnings and errors appropriately for TH splices.
Not done: reporting type-checker warnings for TH splices.
* Some small refactoring around Safe Haskell inference, in order
to keep separate classes of messages separate.
* Some small refactoring around initDsTc, in order to keep separate
classes of messages separate.
* Separate out the generation of messages (that is, the construction
of the text block) from the wrapping of messages (that is, assigning
a SrcSpan). This is more modular than the previous design, which
mixed the two.
Close #19746.
This was a collaborative effort by Alfredo di Napoli and
Richard Eisenberg, with a key assist on #19746 by Iavor
Diatchki.
Metric Increase:
MultiLayerModules
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, the `Outputable` instance for `HsArg` was being used to
pretty-print each `HsArgPar` in a list of `HsArg`s individually, which
simply doesn't work. In lieu of the `Outputable` instance, we now use
a dedicated `pprHsArgsApp` function to print a list of `HsArg`s as a single
unit. I have also added documentation to the `Outputable` instance for `HsArg`
to more clearly signpost that it is only suitable for debug pretty-printing.
Fixes #19737.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The main idea here is to avoid treating
* case e of {}
* case unsafeEqualityProof of UnsafeRefl co -> blah
specially in CoreToStg. Instead, nail them in CorePrep,
by converting
case e of {}
==> e |> unsafe-co
case unsafeEqualityProof of UnsafeRefl cv -> blah
==> blah[unsafe-co/cv]
in GHC.Core.Prep. Now expressions that we want to treat as trivial
really are trivial. We can get rid of cpExprIsTrivial.
And we fix #19700.
A downside is that, at least under unsafeEqualityProof, we substitute
in types and coercions, which is more work. But a big advantage is
that it's all very simple and principled: CorePrep really gets rid of
the unsafeCoerce stuff, as it does empty case, runRW#, lazyId etc.
I've updated the overview in GHC.Core.Prep, and added
Note [Unsafe coercions] in GHC.Core.Prep
Note [Implementing unsafeCoerce] in base:Unsafe.Coerce
We get 3% fewer bytes allocated when compiling perf/compiler/T5631,
which uses a lot of unsafeCoerces. (It's a happy-generated parser.)
Metric Decrease:
T5631
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before we would get the incorrect error message saying that the
rexporting package was the same as the defining package.
I think this only affects error messages for now.
```
- it is bound as p-0.1.0.0:P2 by a reexport in package p-0.1.0.0
- it is bound as P by a reexport in package p-0.1.0.0
+ it is bound as p-0.1.0.0:P2 by a reexport in package q-0.1.0.0
+ it is bound as P by a reexport in package r-0.1.0.0
```
and the output of `-ddump-mod-map` claimed..
```
Moo moo-0.0.0.1 (hidden package, reexport by moo-0.0.0.1)
```
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously Unarise would happily project lifted and unlifted fields
to lifted slots. This broke horribly in #19645, where a ByteArray# was
passed in a lifted slot and consequently entered. The simplest way to
fix this is what I've done here, distinguishing between lifted and
unlifted slots in unarise.
However, one can imagine more clever solutions, where we coerce the
binder to the correct levity with respect to the sum's tag. I doubt that
this would be worth the effort.
Fixes #19645.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
When -dynamic-too is enabled, there are two result files, .o and .dyn_o,
therefore we should check both to decide whether to set SourceModified
or not.
The whole recompilation logic is very messy, a more thorough refactor
would be beneficial in this area but this is the minimal patch to fix
this more high priority problem.
Fixes #17968 and hopefully #17534
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In another small step towards bringing a manageable variant of Nested
CPR into GHC, this patch refactors worker/wrapper to be able to exploit
Nested CPR signatures. See the new Note [Worker/wrapper for CPR].
The nested code path is currently not triggered, though, because all
signatures that we annotate are still flat. So purely a refactoring.
I am very confident that it works, because I ripped it off !1866 95%
unchanged.
A few test case outputs changed, but only it's auxiliary names only.
I also added test cases for #18109 and #18401.
There's a 2.6% metric increase in T13056 after a rebase, caused by an
additional Simplifier run. It appears b1d0b9c saw a similar additional
iteration. I think it's just a fluke.
Metric Increase:
T13056
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Remove EpaAnn type synonym, rename EpaAnn' to EpaAnn.
Closes #19705
Updates haddock submodule
--
Change
data EpaAnchor = AR RealSrcSpan
| AD DeltaPos
To instead be
data EpaAnchor = AnchorReal RealSrcSpan
| AnchorDelta DeltaPos
Closes #19699
--
Change
data DeltaPos =
DP
{ deltaLine :: !Int,
deltaColumn :: !Int
}
To instead be
data DeltaPos
= SameLine { deltaColumn :: !Int }
| DifferentLine { deltaLine :: !Int, startColumn :: !Int }
Closes #19698
--
Also some clean-ups of unused parts of check-exact.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since d880d6b2e48268f5ed4d3eb751fe24cc833e9221 the parsing of the
environment files was moved to `parseDynamicFlags`, under the assumption
it was typically only called once. It turns out not to be true in GHCi
and this led to continually reparsing the environment file whenever a
new option was set, the options were appended to the package state and
hence all packages reloaded, as it looked like the options were changed.
The simplest fix seems to be a clearer specification:
> Package environment files are only loaded in GHCi during initialisation.
Fixes #19650
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Allow under-saturated calls to specialise
See Note [SpecConstr call patterns]
This just allows a bit more specialisation to take place.
* Don't discard calls from un-specialised RHSs. This was
a plain bug in `specialise`, again leading to loss of
specialisation. Refactoring yields an `otherwise`
case that is easier to grok.
* I refactored CallPat to become a proper data type, not a tuple.
All this came up when I was working on eta-reduction. The ticket
is #19672.
The nofib results are mostly zero, with a couple of big wins:
Program Size Allocs Runtime Elapsed TotalMem
--------------------------------------------------------------------------------
awards +0.2% -0.1% -18.7% -18.8% 0.0%
comp_lab_zift +0.2% -0.2% -23.9% -23.9% 0.0%
fft2 +0.2% -1.0% -34.9% -36.6% 0.0%
hpg +0.2% -0.3% -18.4% -18.4% 0.0%
mate +0.2% -15.7% -19.3% -19.3% +11.1%
parser +0.2% +0.6% -16.3% -16.3% 0.0%
puzzle +0.4% -19.7% -33.7% -34.0% 0.0%
rewrite +0.2% -0.5% -20.7% -20.7% 0.0%
--------------------------------------------------------------------------------
Min +0.2% -19.7% -48.1% -48.9% 0.0%
Max +0.4% +0.6% -1.2% -1.1% +11.1%
Geometric Mean +0.2% -0.4% -21.0% -21.1% +0.1%
I investigated the 0.6% increase on 'parser'. It comes because SpecConstr
has a limit of 3 specialisations. With HEAD, hsDoExpr has 2
specialisations, and then a further several from the specialised
bodies, of which 1 is picked. With this patch we get 3
specialisations right off the bat, so we discard all from the
recursive calls. Turns out that that's not the best choice, but there
is no way to tell that. I'm accepting it.
NB: these figures actually come from this patch plus the preceding one for
StgCSE, but I think the gains come from SpecConstr.
|
|
|
|
|
|
|
|
| |
This patch fixes #19717, a long-standing bug in CSE for STG, which
led to a stupid loss of CSE in some situations.
It's explained in Note [Trivial case scrutinee], which I have
substantially extended.
|
|
|
|
|
|
|
|
|
|
| |
There were two different issues:
1. integralFractionalLit needed to be passed an already negated value. (T19680)
2. negateFractionalLit did not actually negate the argument, only
flipped the negation flag. (T19680A)
Fixes #19680
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This vastly reduces memory usage when compiling with `--make` mode, from
about 900M when compiling Cabal to about 300M.
As a matter of uniformity, it also ensures that reading from an
interface performs the same as using the in-memory cache. We can also
delete all the horrible knot-tying in updateIdInfos.
Goes some way to fixing #13586
Accept new output of tests fixing some bugs along the way
-------------------------
Metric Decrease:
T12545
-------------------------
|
|
|
|
| |
Fixes #19688.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Ticket #13873 unexpectedly showed that a SPECIALISE pragma made a
program run (a lot) slower, because less specialisation took place
overall. It turned out that the specialiser was missing opportunities
because of quantified type variables.
It was quite easy to fix. The story is given in
Note [Specialising polymorphic dictionaries]
Two other minor fixes in the specialiser
* There is no benefit in specialising data constructor /wrappers/.
(They can appear overloaded because they are given a dictionary
to store in the constructor.) Small guard in canSpecImport.
* There was a buglet in the UnspecArg case of specHeader, in the
case where there is a dead binder. We need a LitRubbish filler
for the specUnfolding stuff. I expanded
Note [Drop dead args from specialisations] to explain.
There is a 4% increase in compile time for T13056, because we generate
more specialised code. This seems OK.
Metric Increase:
T13056
|
|
|
|
|
| |
This makes it more robust to people running it with `quick` flavour and
so on.
|
|
|
|
| |
Fixes #19615
|
|
|
|
|
|
| |
Otherwise, errors can go missing which arise when running the splices.
Fixes #19470
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We want an accurate SrcSpan for redundant constraints:
• Redundant constraint: Eq a
• In the type signature for:
f :: forall a. Eq a => a -> ()
|
5 | f :: Eq a => a -> ()
| ^^^^
This patch adds some plumbing to achieve this
* New data type GHC.Tc.Types.Origin.ReportRedundantConstraints (RRC)
* This RRC value is kept inside
- FunSigCtxt
- ExprSigCtxt
* Then, when reporting the error in GHC.Tc.Errors, use this SrcSpan
to control the error message: GHC.Tc.Errors.warnRedundantConstraints
Quite a lot of files are touched in a boring way.
|
|
|
|
|
|
|
|
|
|
|
| |
The problem was that ghci inserts some ticks around the crucial bit of
the expression. Just like in some of the other rules we now strip the
ticks so that the rule fires more reliably.
It was possible to defeat magicDict by using -fhpc as well, so not just an
issue in ghci.
Fixes #19667 and related to #19673
|
|
|
|
| |
--ignore-perf-failures
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
With this patch we switch from reading the globally installed
platformConstants file to reading the DerivedConstants.h header file
that is bundled in the RTS unit. When we build the RTS unit itself, we
get it from its includes directories.
The new parser is more efficient and strict than the Read instance for
PlatformConstants and we get about 2.2MB less allocations in every
cases. However it only really shows in tests that don't allocate much,
hence the following metric decreases.
Metric Decrease:
Naperian
T10421
T10547
T12150
T12234
T12425
T13035
T18304
T18923
T5837
T6048
T18140
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Kick out condition K2b really only makes sense for
inerts with a type variable on the left. This updates
the commentary and the code to skip this check for
inerts with type families on the left.
Also cleans up some commentary around solver invariants
and adds Note [K2b].
Close #19042.
test case: typecheck/should_compile/T19042
|
|
|
|
|
| |
The test max memory usage improves dramatically with the fixes to
memory usage in demand analyser from #15455
|
| |
|
| |
|
|
|
|
|
|
|
| |
In commit f3c23939 T18623 is disabled for aarch64.
The limit seems to be too low for powerpc64le, too. This could be
because tables next to code is not supported and our code generator
produces larger code on PowerPC.
|
|
|
|
|
|
|
|
|
|
| |
Previously, associated type family instances would incorrectly claim to
implicitly quantify over type variables bound by the instance head in the
`HsOuterImplicit`s that `rnFamEqn` returned. This is fixed by using
`filterInScopeM` to filter out any type variables that the instance head
binds.
Fixes #19649.
|
|
|
|
| |
Fixes #11545
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Dynamic-by-default was a mechanism to automatically select the -dynamic
way for some targets.
It was implemented in a convoluted way: it was defined as a flavour
option, hence it couldn't be passed as a global settings (which are
produced by `configure` before considering flavours), so a build system
rule was used to pass -DDYNAMIC_BY_DEFAULT to the C compiler so that
deriveConstants could infer it.
* Make build system has it disabled for 8 years (951e28c0625ece7e0db6ac9d4a1e61e2737b10de)
* It has never been implemented in Hadrian
* Last time someone tried to enable it 1 year ago it didn't work (!2436)
* Having this as a global constant impedes making GHC multi-target (see !5427)
This commit fully removes support for dynamic-by-default. If someone
wants to reimplement something like this, it would probably need to move
the logic in the compiler.
(Doing this would probably need some refactoring of the way the compiler
handles DynFlags: DynFlags are used to store and to pass enabled ways to
many parts of the compiler. It can be set by command-line flags, GHC
API, global settings. In multi-target GHC, we will use DynFlags to load
the target platform and its constants: but at this point with the
current DynFlags implementation we can't easily update the existing
DynFlags with target-specific options such as dynamic-by-default without
overriding ways previously set by the user.)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The patch
commit c43c981705ec33da92a9ce91eb90f2ecf00be9fe
Author: Simon Peyton Jones <simonpj@microsoft.com>
Date: Fri Oct 23 16:15:51 2009 +0000
Fix Trac #3591: very tricky specialiser bug
fixed a nasty specialisation bug /for DFuns/. Eight years
later, this patch
commit 2b74bd9d8b4c6b20f3e8d9ada12e7db645cc3c19
Author: Simon Peyton Jones <simonpj@microsoft.com>
Date: Wed Jun 7 12:03:51 2017 +0100
Stop the specialiser generating loopy code
extended it to work for /imported/ DFuns. But in the process
we lost the fact that it was needed only for DFuns! As a result
we started silently losing useful specialisation for non-DFuns.
But there was no regression test to spot the lossage.
Then, nearly four years later, Andreas filed #19599, which showed
the lossage in high relief. This patch restores the DFun test,
and adds Note [Avoiding loops (non-DFuns)] to explain why.
This is undoubtedly a very tricky corner of the specialiser,
and one where I would love to have a more solid argument, even a
paper! But meanwhile I think this fixes the lost specialisations
without introducing any new loops.
I have two regression tests, T19599 and T19599a, so I hope we'll
know if we lose them again in the future.
Vanishingly small effect on nofib.
A couple of compile-time benchmarks improve
T9872a(normal) ghc/alloc 1660559328.0 1643827784.0 -1.0% GOOD
T9872c(normal) ghc/alloc 1691359152.0 1672879384.0 -1.1% GOOD
Many others wiggled around a bit.
Metric Decrease:
T9872a
T9872c
|
|
|
|
| |
This reverts commit 0cbdba2768d84a0f6832ae5cf9ea1e98efd739da.
|
| |
|
|
|
|
| |
See #17018.
|
|
|
|
|
|
|
| |
In version 0.12.2.0 of vector when used with GHC-9.0 we
rebox values from storeable mutable vectors.
This should catch such a change in the future.
|
| |
|