| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Test Plan: harbormaster
Reviewers: austin, bgamari
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D2947
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, we had the following parser:
xs : xs ';' x
| xs ';'
| x
This is a very clever construction that handles duplicate,
leading and trailing semicolons well, but it didn't work very
well with annotations, where we wanted to attach the annotation
for a semicolon to the *previous* x in the list. This lead
to some very disgusting code in the parser.
This commit refactors the parser into this form:
semis1 : semis1 ';'
| ';'
xs_semi : xs x semis1
| {- empty -}
xs : xs_semi x
Now, when we parse one or more semicolons after an x, we can
attach them immediately, eliminating some very grotty annotations
swizzling that was previously in the parser.
We now need to write the top-level parser for imports and then
declarations in a slightly special way now:
top : semis top1
top1 : importdecls_semi topdecls_semi
| importdecls_semi topdecls
| importdecls
This is because the *_semi parsers always require a semicolon,
but we're allowed to omit that last newline. So we need
special cases to handle each of the possible cases where we
may run out of semicolons. I don't know if there is a better
way to structure this, but it is not much more complicated
than what we had before for top (and asymptotically better!)
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
Test Plan: validate
Reviewers: simonmar, austin, alanz, bgamari
Reviewed By: alanz, bgamari
Subscribers: thomie, mpickering
Differential Revision: https://phabricator.haskell.org/D2893
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously when encountering EAsPat in an expression context,
TypeApplications was suggested even when already enabled. This patch
replaces the suggestion with more appropriate message.
Test Plan: validate
Reviewers: austin, bgamari, mpickering, goldfire, simonpj
Reviewed By: mpickering, goldfire, simonpj
Subscribers: simonpj, goldfire, mpickering, thomie
Differential Revision: https://phabricator.haskell.org/D2877
GHC Trac Issues: #12879
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As noted in #12837, these classes are special and the user should
not be able to define their own instances.
Test Plan: Validate
Reviewers: adamgundry, goldfire, mpickering, austin, bgamari
Reviewed By: goldfire, mpickering
Subscribers: goldfire, mpickering, thomie
Differential Revision: https://phabricator.haskell.org/D2898
GHC Trac Issues: #12837
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Originally, everything that is not in WHNF (`exprIsWHNF`) is considered
a thunk, not eta-expanded, to avoid losing any sharing. This is also how
the published papers on Call Arity describe it.
In practice, there are thunks that do a just little work, such as
pattern-matching on a variable, and the benefits of eta-expansion likely
oughtweigh the cost of doing that repeatedly. Therefore, this
implementation of Call Arity considers everything that is not cheap
(`exprIsCheap`) as a thunk.
Nofib reports -2.58% allocations for scs and -40.93% allocation for
wheel-sieve1; the latter has - 2.92% runtime.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is controlled by -f[no-]diagnostics-show-caret.
Example of what it looks like:
```
|
42 | x = 1 + ()
| ^^^^^^
```
This is appended to each diagnostic message.
Test Plan:
testsuite/tests/warnings/should_fail/CaretDiagnostics1
testsuite/tests/warnings/should_fail/CaretDiagnostics2
Reviewers: simonpj, austin, bgamari
Reviewed By: simonpj, bgamari
Subscribers: joehillen, mpickering, Phyx, simonpj, alanz, thomie
Differential Revision: https://phabricator.haskell.org/D2718
GHC Trac Issues: #8809
|
|
|
|
| |
Fixes #11216.
|
|
|
|
|
|
|
|
|
|
| |
Trac #13025 showed up the fact that exprIsConApp_maybe isn't
clever enough: it didn't push coercions through applicatins, and that
meant we weren't getting as much superclass selection as we should.
It's easy to fix, happily.
See Note [Push coercions in exprIsConApp_maybe]
|
|
|
|
| |
Fixes Trac #13029 by deleting code and adding comments
|
|
|
|
|
|
|
|
|
|
| |
This was provoked by Trac #13027.
The fix in Simplify actually cures the reported bug; see
Note [Case binder evaluated-ness] in Simplify.
The fix in CoreTidy looks like an omission that I fixed while I
was at it.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch makes GHC's floating more robust, by allowing it
to float unboxed expressions of at least some common types.
See Note [Floating MFEs of unlifted type] in SetLevels.
This was all provoked by Trac #12603
In working this through I also made a number of other corner-case
changes in SetLevels:
* Previously we inconsistently use exprIsBottom (which checks for
bottom) instead of exprBotStrictness_maybe (which checks for
bottoming functions). As well as being inconsistent it was
simply less good.
See Note [Bottoming floats]
* I fixed a case where were were unprofitably floating an
expression because we thought it escaped a value lambda
(see Note [Escaping a value lambda]). The relevant code is
float_me = (dest_lvl `ltMajLvl` (le_ctxt_lvl env)
&& not float_is_lam) -- NEW
* I made lvlFloatRhs work properly in the case where abs_vars
is non-empty. It wasn't wrong before, but it did some stupid
extra floating.
|
|
|
|
|
|
|
|
|
|
|
| |
The payload of this change is to ensure that a bottoming function
still has an unfolding, just one with an UnfoldingGuidance of
UnfoldNever.
Previously it was getting an unfolding of NoUnfolding. I don't think
that was really /wrong/, but it was inconsistent with the general
principle of giving everthing an unfoding if we know it. And it
seems tideier this way.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
See Note [ABot branches: use max] in CoreArity.
I stumbled on this when investigating something else, and
opened Trac #13031 to track it.
It's very hard to tickle the bug, which is why it has lurked so long,
but the test
stranal/should_compile/T13031
does so
Oddly, the testsuite framework doesn't actually run the test; I have
no idea why.
|
| |
|
|
|
|
|
|
| |
A continuation of ccc918cdc8b2d147c4dbc29bfc87c058862a97cd.
[ci skip]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Maybe everyone knows this but I think it is worth mentioning
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
Test Plan: none
Reviewers: bgamari, austin
Subscribers: thomie, mpickering
Differential Revision: https://phabricator.haskell.org/D2890
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This is a complete fix based off of
ed7af26606b3a605a4511065ca1a43b1c0f3b51d for handling
shadowing and out-of-order -package-db flags simultaneously.
The general strategy is we first put all databases together,
overriding packages as necessary. Once this is done, we successfully
prune out broken packages, including packages which depend on a package
whose ABI differs from the ABI we need.
Our check gracefully degrades in the absence of abi-depends, as
we only check deps which are recorded in abi-depends.
Contains time and Cabal submodule update.
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
Test Plan: validate
Reviewers: niteria, austin, bgamari
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D2846
GHC Trac Issues: #12485
|
|
|
|
|
|
| |
It turns out there were two Notes in the GHC codebase named
[Pattern synonym signatures]. To avoid confusion, I gave one Note a slightly
different name.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Trac #12944 showed that the DsBinds code that implemented a
SPECIALISE pragma was inadequate if the constraints solving
added let-bindings for dictionaries. The result was that
we ended up with an unbound dictionary in a DFunUnfolding -- and
Lint didn't even check for that!
Fixing this was not entirely straightforward
* In DsBinds.dsSpec we use a new function
TcEvidence.collectHsWrapBinders
to pick off the lambda binders from the HsWapper
* dsWrapper now returns a (CoreExpr -> CoreExpr) function
* CoreUnfold.specUnfolding now takes a (CoreExpr -> CoreExpr)
function it can use to specialise the unfolding.
On the whole the code is simpler than before.
|
|
|
|
|
|
|
|
|
| |
While fixing Trac #12444 I found an occasion on which we applied
worker/wrapper to a DFunId. This is bad: it destroys the magic
DFunUnfolding.
This patch is a minor refactoring that stops this corner case
happening, and tidies up the code a bit too.
|
|
|
|
|
|
|
|
| |
It turned out that many different modules defined the same type
synonyms (InId, OutId, InType, OutType, etc) for the same purpose.
This patch is refactoring only: it moves all those definitions to
CoreSyn.
|
|
|
|
|
| |
Previously we simply failed to Lint these DFunUnfoldings, which led
to a very delayed error message for Trac #12944
|
|
|
|
|
| |
See SimplUtils Note [No eta expansion in stable unfoldings],
and Trac #9509 for an excellend diagnosis by Nick Frisby
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
While investigating something else I found that 'typeSize' was
allocating like crazy. Stupid becuase it should allocate precisely
nothing!!
Turned out that it was because typeSize and coercionSize were mutually
recursive across module boundaries, and so could not benefit from the
CPR property. To fix this I moved them both into TyCoRep.
It's not critical (because typeSize is really only used in
debug mode, but I tripped over and example (T5642) in which
typeSize was one of the biggest single allocators in all of GHC.
And it's easy to fix, so I did.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Based off my understanding of how the moving parts work.
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
Test Plan: comments only
Reviewers: alanz, mpickering, austin, bgamari
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D2887
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Now that we have -fexternal-interpreter, we can lose most of the GHCI ifdefs.
This was originally added in https://phabricator.haskell.org/D2826
but that led to a compatibility issue with ghc 7.10.x on Windows.
That's fixed here and the revert reverted.
Reviewers: goldfire, hvr, austin, bgamari, Phyx
Reviewed By: Phyx
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D2884
GHC Trac Issues: #13008
|
|
|
|
| |
This reverts commit 52ba9470a7e85d025dc84a6789aa809cdd68b566.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
In D2448 (which introduced Template Haskell support for unboxed
sums), I neglected to add `unboxedSumDataName` and `unboxedSumTypeName`
functions, since there wasn't any way you could write unboxed sum data or type
constructors in prefix form to begin with (see #12514). But even if you can't
write these `Name`s directly in source code, it would still be nice to be able
to use these `Name`s in Template Haskell (for instance, to be able to treat
unboxed sum type constructors like any other type constructors).
Along the way, this uncovered a minor bug in `isBuiltInOcc_maybe` in
`TysWiredIn`, which was calculating the arity of unboxed sum data constructors
incorrectly.
Test Plan: make test TEST=T12478_5
Reviewers: osa1, goldfire, austin, bgamari
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D2854
GHC Trac Issues: #12478, #12514
|
|
|
|
| |
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
With hs-boot files, some type families may be defined in the
module we are typechecking. In this case, we are not allowed
to poke these families until after we typecheck our local
declarations. So we first check everything involving non-recursive
families, and then check the recursive families as we finish
kind-checking them.
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
Test Plan: validate
Reviewers: goldfire, austin, simonpj, bgamari
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D2859
GHC Trac Issues: #11062
|
|
|
|
|
|
|
|
|
|
|
|
| |
Now that we have -fexternal-interpreter, we can lose most of the GHCI ifdefs.
Reviewers: simonmar, goldfire, austin, hvr, bgamari
Reviewed By: simonmar
Subscribers: RyanGlScott, mpickering, angerman, thomie
Differential Revision: https://phabricator.haskell.org/D2826
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This area of code contains a lot of unsafe functionality, so it might be
worth documenting to reduce the risk of misuse.
Test Plan: inspection
Reviewers: austin, bgamari
Reviewed By: bgamari
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D2872
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The previous detection mechanism allowed environment variables (ANSICON,
ConEmuANSI, TERM) to supersede the fact that the stderr is not a
terminal, which is probably what led to color codes appearing in the
stderr of the tests (see: 847d229346431483b99adcff12e46c7bf6af15da).
This commit changes the detection mechanism to detect Cygwin/MSYS2
terminals in a more reliable manner, avoiding the use of environment
variables entirely.
Test Plan: validate
Reviewers: Phyx, austin, erikd, bgamari
Reviewed By: Phyx, bgamari
Subscribers: RyanGlScott, thomie
Differential Revision: https://phabricator.haskell.org/D2809
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, GHC checked for bad levity polymorphism to the left of all
arrows in data constructors. This was wrong, as reported in #12911
(where an example is also shown). The solution is to check each
individual argument for bad levity polymorphism. Thus the check has
been moved from TcValidity to TcTyClsDecls.
A similar situation exists with pattern synonyms, also fixed here.
This patch also nabs #12819 while I was in town.
Test cases: typecheck/should_compile/T12911, patsyn/should_fail/T12819
Test Plan: ./validate
Reviewers: simonpj, austin, bgamari
Reviewed By: bgamari
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D2783
GHC Trac Issues: #12819, #12911
|
|
|
|
|
| |
This reverts commit 3a00ff92a3ee66c096b85b180d247d1a471a6b6e due
to #12993
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The added flags for string literal merging ended up printed in the
middle of the section name when -split-sections was enabled. Break it up
to put the flags after the name.
Test Plan: validate with SplitSections=YES
Reviewers: austin, bgamari
Reviewed By: bgamari
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D2865
GHC Trac Issues: #9577
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
We used to pass a bottoming Module to the NCG, which resulted in panics
when `-v` was used due to debug output (see #11784). Instead we make up
a module name. This is a bit scary since `PIC.howToAccessLabel` might
actually use the Module, but if it wasn't crashing before I suppose it's
fine.
Test Plan: `touch hi.cmm; ghc -v2 -c -dcmm-lint hi.cmm`
Reviewers: austin, simonmar
Reviewed By: simonmar
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D2864
GHC Trac Issues: #11784
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It already has access to the current package's UnitId via the Module.
Edward Yang pointed out that there is one wrinkle, however: the
following invariant isn't true at all stages of compilation,
if I am compiling the module (this_mod :: Module), then
thisPackage dflags == moduleUnitId this_mod.
Specifically, this is only true after desugaring; it may be broken when
typechecking an indefinite signature.
However, it's safe to assume this in the native codegen. I've updated
Note to state this invariant more directly.
Test Plan: Validate
Reviewers: austin, ezyang, simonmar
Reviewed By: ezyang, simonmar
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D2863
|
|
|
|
|
|
|
|
|
|
| |
Test Plan: Validate
Reviewers: austin, simonmar
Subscribers: thomie, ezyang
Differential Revision: https://phabricator.haskell.org/D2866
|
|
|
|
|
|
|
|
|
|
|
|
| |
Test Plan: Validate
Reviewers: austin
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D2862
GHC Trac Issues: #11221
|