| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This implements the ideas originally put forward in
"System FC with Explicit Kind Equality" (ICFP'13).
There are several noteworthy changes with this patch:
* We now have casts in types. These change the kind
of a type. See new constructor `CastTy`.
* All types and all constructors can be promoted.
This includes GADT constructors. GADT pattern matches
take place in type family equations. In Core,
types can now be applied to coercions via the
`CoercionTy` constructor.
* Coercions can now be heterogeneous, relating types
of different kinds. A coercion proving `t1 :: k1 ~ t2 :: k2`
proves both that `t1` and `t2` are the same and also that
`k1` and `k2` are the same.
* The `Coercion` type has been significantly enhanced.
The documentation in `docs/core-spec/core-spec.pdf` reflects
the new reality.
* The type of `*` is now `*`. No more `BOX`.
* Users can write explicit kind variables in their code,
anywhere they can write type variables. For backward compatibility,
automatic inference of kind-variable binding is still permitted.
* The new extension `TypeInType` turns on the new user-facing
features.
* Type families and synonyms are now promoted to kinds. This causes
trouble with parsing `*`, leading to the somewhat awkward new
`HsAppsTy` constructor for `HsType`. This is dispatched with in
the renamer, where the kind `*` can be told apart from a
type-level multiplication operator. Without `-XTypeInType` the
old behavior persists. With `-XTypeInType`, you need to import
`Data.Kind` to get `*`, also known as `Type`.
* The kind-checking algorithms in TcHsType have been significantly
rewritten to allow for enhanced kinds.
* The new features are still quite experimental and may be in flux.
* TODO: Several open tickets: #11195, #11196, #11197, #11198, #11203.
* TODO: Update user manual.
Tickets addressed: #9017, #9173, #7961, #10524, #8566, #11142.
Updates Haddock submodule.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Test Plan: validate
Reviewers: austin, goldfire, simonpj, bgamari
Reviewed By: bgamari
Subscribers: rwbarton, thomie
Differential Revision: https://phabricator.haskell.org/D1110
GHC Trac Issues: #10706
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
In this commit
commit 0696fc6d4de28cb589f6c751b8491911a5baf774
Author: Simon Peyton Jones <simonpj@microsoft.com>
Date: Fri Jun 26 11:40:01 2015 +0100
I made an error in the is_var_scrut tests in extendEnvForProdAlt.
This patch fixes it, thereby fixing Trac #10694.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Two things here:
* For exceptions-catching primops like catch#, we know
that the main argument function will be called, so
we can use strictApply1Dmd, rather than lazy
Changes in primops.txt.pp
* When a 'case' scrutinises a I/O-performing primop,
the Note [IO hack in the demand analyser] was
throwing away all strictness from the code that
followed.
I found that this was causing quite a bit of unnecessary
reboxing in the (heavily used) function
GHC.IO.Handle.Internals.wantReadableHandle
So this patch prevents the hack applying when the
case scrutinises a primop. See the revised
Note [IO hack in the demand analyser]
Thse two things buy us quite a lot in programs that do a lot of IO.
Program Size Allocs Runtime Elapsed TotalMem
--------------------------------------------------------------------------------
hpg -0.4% -2.9% -0.9% -1.0% +0.0%
reverse-complem -0.4% -10.9% +10.7% +10.9% +0.0%
simple -0.3% -0.0% +26.2% +26.2% +3.7%
sphere -0.3% -6.3% 0.09 0.09 +0.0%
--------------------------------------------------------------------------------
Min -0.7% -10.9% -4.6% -4.7% -1.7%
Max -0.2% +0.0% +26.2% +26.2% +6.5%
Geometric Mean -0.4% -0.3% +2.1% +2.1% +0.1%
I think the increase in runtime for 'simple' is measurement error.
|
|
|
|
|
| |
Lacking this cuased Trac #10658.
The fix is easy; it was a simple omission.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When working on Trac #10482 I noticed that we could give constructor
arguments the CPR property if they are use strictly.
This is documented carefully in
Note [CPR in a product case alternative]
and also
Note [Initial CPR for strict binders]
There are a bunch of intersting examples in
Note [CPR examples]
which I have added to the test suite as T10482a.
I also added a test for #10482 itself.
|
|
|
|
|
|
|
|
|
|
|
|
| |
See Note [Add demands for strict constructors].
The new bit is the test for isAbsDmd in addDataConStrictness.
There was a cryptic note that said that this function
should add a seqDmd even for Absent arguments, but that
is definitely a bad thing (as the Note now says), causing
unused arguments to be passed to the worker.
Easy fix!
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Make tuple constraints be handled by a perfectly ordinary
type class, with the component constraints being the
superclasses:
class (c1, c2) => (c2, c2)
This change was provoked by
#10359 inability to re-use a given tuple
constraint as a whole
#9858 confusion between term tuples
and constraint tuples
but it's generally a very nice simplification. We get rid of
- In Type, the TuplePred constructor of PredTree,
and all the code that dealt with TuplePreds
- In TcEvidence, the constructors EvTupleMk, EvTupleSel
See Note [How tuples work] in TysWiredIn.
Of course, nothing is ever entirely simple. This one
proved quite fiddly.
- I did quite a bit of renaming, which makes this patch
touch a lot of modules. In partiuclar tupleCon -> tupleDataCon.
- I made constraint tuples known-key rather than wired-in.
This is different to boxed/unboxed tuples, but it proved
awkward to have all the superclass selectors wired-in.
Easier just to use the standard mechanims.
- While I was fiddling with known-key names, I split the TH Name
definitions out of DsMeta into a new module THNames. That meant
that the known-key names can all be gathered in PrelInfo, without
causing module loops.
- I found that the parser was parsing an import item like
T( .. )
as a *data constructor* T, and then using setRdrNameSpace to
fix it. Stupid! So I changed the parser to parse a *type
constructor* T, which means less use of setRdrNameSpace.
I also improved setRdrNameSpace to behave better on Exact Names.
Largely on priciple; I don't think it matters a lot.
- When compiling a data type declaration for a wired-in thing like
tuples (,), or lists, we don't really need to look at the
declaration. We have the wired-in thing! And not doing so avoids
having to line up the uniques for data constructor workers etc.
See Note [Declarations for wired-in things]
- I found that FunDeps.oclose wasn't taking superclasses into
account; easily fixed.
- Some error message refactoring for invalid constraints in TcValidity
- Haddock needs to absorb the change too; so there is a submodule update
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts multiple commits from Simon:
- 04a484eafc9eb9f8774b4bdd41a5dc6c9f640daf Test Trac #10359
- a9ccd37add8315e061c02e5bf26c08f05fad9ac9 Test Trac #10403
- c0aae6f699cbd222d826d0b8d78d6cb3f682079e Test Trac #10248
- eb6ca851f553262efe0824b8dcbe64952de4963d Make the "matchable-given" check happen first
- ca173aa30467a0b1023682d573fcd94244d85c50 Add a case to checkValidTyCon
- 51cbad15f86fca1d1b0e777199eb1079a1b64d74 Update haddock submodule
- 6e1174da5b8e0b296f5bfc8b39904300d04eb5b7 Separate transCloVarSet from fixVarSet
- a8493e03b89f3b3bfcdb6005795de050501f5c29 Fix imports in HscMain (stage2)
- a154944bf07b2e13175519bafebd5a03926bf105 Two wibbles to fix the build
- 5910a1bc8142b4e56a19abea104263d7bb5c5d3f Change in capitalisation of error msg
- 130e93aab220bdf14d08028771f83df210da340b Refactor tuple constraints
- 8da785d59f5989b9a9df06386d5bd13f65435bc0 Delete commented-out line
These break the build by causing Haddock to fail mysteriously when
trying to examine GHC.Prim it seems.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Make tuple constraints be handled by a perfectly ordinary
type class, with the component constraints being the
superclasses:
class (c1, c2) => (c2, c2)
This change was provoked by
#10359 inability to re-use a given tuple
constraint as a whole
#9858 confusion between term tuples
and constraint tuples
but it's generally a very nice simplification. We get rid of
- In Type, the TuplePred constructor of PredTree,
and all the code that dealt with TuplePreds
- In TcEvidence, the constructors EvTupleMk, EvTupleSel
See Note [How tuples work] in TysWiredIn.
Of course, nothing is ever entirely simple. This one
proved quite fiddly.
- I did quite a bit of renaming, which makes this patch
touch a lot of modules. In partiuclar tupleCon -> tupleDataCon.
- I made constraint tuples known-key rather than wired-in.
This is different to boxed/unboxed tuples, but it proved
awkward to have all the superclass selectors wired-in.
Easier just to use the standard mechanims.
- While I was fiddling with known-key names, I split the TH Name
definitions out of DsMeta into a new module THNames. That meant
that the known-key names can all be gathered in PrelInfo, without
causing module loops.
- I found that the parser was parsing an import item like
T( .. )
as a *data constructor* T, and then using setRdrNameSpace to
fix it. Stupid! So I changed the parser to parse a *type
constructor* T, which means less use of setRdrNameSpace.
I also improved setRdrNameSpace to behave better on Exact Names.
Largely on priciple; I don't think it matters a lot.
- When compiling a data type declaration for a wired-in thing like
tuples (,), or lists, we don't really need to look at the
declaration. We have the wired-in thing! And not doing so avoids
having to line up the uniques for data constructor workers etc.
See Note [Declarations for wired-in things]
- I found that FunDeps.oclose wasn't taking superclasses into
account; easily fixed.
- Some error message refactoring for invalid constraints in TcValidity
|
|
|
|
|
|
|
|
| |
This fixes a typo in d5773a4939b1feea51ec0db6624c9462751e948a
Teach DmdAnal that coercions are value arguments!
(Trac #10288)
Sorry about that; I'm not sure how it slipped through.
|
|
|
|
|
|
|
|
|
|
|
|
| |
Beofre this commit we never unboxed GADT, even if they
are perfectly civilised products.
This patch liberalises unboxing slightly.
See Note [Product types] in TyCon.
Still to come
- for strictness, we could maybe deal with existentials too
- todo: unboxing constructor arguments
|
|
|
|
|
|
|
|
|
|
|
| |
Coercion variables are used in casts and coercions, so the demand
analyser should jolly well not regard them as absent!
In fact this bug never makes a difference because even absent
unboxed-coercion arguments are passed anyway;
see WwLib.mk_abesnt_let, which returns Nothing for coercion Ids.
But it was simply wrong before and that is never cool.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The demand analyser was treating coercion args like type args,
which meant that the arguments in a strictness signature got
out of step with the arguments of a call. Result chaos and
disaster. Trac #10288 showed it up.
It's hard to get this bug to show up in practice because
- functions abstracted over coercions are usually abstracted
over *boxed* coercions
- we don't currently unbox a boxed-coercion arg because it's
GADT (I see how to fix this too)
But after floating, optimisation, and so on, Trac #10288 did
get a function abstracted over an unboxed coercion, and then
the -flate-dmd-anal pass went wrong.
I don't think I can come up with a test case, but I don't think
it matters too much.
Still to come
- Fix a second bug, namely that coercion variables are wrongly
marked as absent because DmdAnal doesn't check the the free
variables of casts. I think this never bites in practice
(see the follow-up commit)
- Make GADT products work with strictness analysis
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Trac #10218 reports a subtle bug that turned out to be:
- CSE invalidated the usage information computed
by earlier demand analysis, by increasing sharing
- that made a single-entry thunk into a multi-entry thunk
- and with -feager-blackholing, that led to <<loop>>
The patch fixes it by making the CSE pass zap usage information for
let-bound identifiers. It can be restored by -flate-dmd-anal.
(But making -flate-dmd-anal the default needs some careful work;
see Trac #7782.)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch fixes Trac #10148, an outright and egregious
bug in the demand analyser.
It is explained in Note [Demand on case-alternative binders]
in Demand.hs.
I did some other minor refactoring.
To my astonishment I got some big compiler perf changes
* perf/compiler/T5837: bytes allocated -76%
* perf/compiler/T5030: bytes allocated -10%
* perf/compiler/T3294: max bytes used -25%
Happy days
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: It looks like during .lhs -> .hs switch the comments were not updated. So doing exactly that.
Reviewers: austin, jstolarek, hvr, goldfire
Reviewed By: austin, jstolarek
Subscribers: thomie, goldfire
Differential Revision: https://phabricator.haskell.org/D621
GHC Trac Issues: #9986
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
HsTyLit now has SourceText
Update documentation of HsSyn to reflect which annotations are attached to which element.
Ensure that the parser always keeps HsSCC and HsTickPragma values, to
be ignored in the desugar phase if not needed
Bringing in SourceText for pragmas
Add Location in NPlusKPat
Add Location in FunDep
Make RecCon payload Located
Explicitly add AnnVal to RdrName where it is compound
Add Location in IPBind
Add Location to name in IEThingAbs
Add Maybe (Located id,Bool) to Match to track fun_id,infix
This includes converting Match into a record and adding a note about why
the fun_id needs to be replicated in the Match.
Add Location in KindedTyVar
Sort out semi-colons for parsing
- import statements
- stmts
- decls
- decls_cls
- decls_inst
This updates the haddock submodule.
Test Plan: ./validate
Reviewers: hvr, austin, goldfire, simonpj
Reviewed By: simonpj
Subscribers: thomie, carter
Differential Revision: https://phabricator.haskell.org/D538
|
|
|
|
|
|
| |
Reviewed By: austin
Differential Revision: https://phabricator.haskell.org/D541
|
| |
|
| |
|
|
|
|
|
| |
See Note [Activation for INLINABLE worker]. This was preventing
Trac #6056 from working.
|
|
|
|
|
|
| |
The "InlineRule" is gone now, so this is just making the comments line
up with the code. A function does change its name though:
updModeForInlineRules --> updModeForStableUnfoldings
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes a long-standing bug: Trac #6056. The trouble was that
INLINEABLE "used up" the unfolding for the Id, so it couldn't be
worker/wrapper'd by the strictness analyser.
This patch allows the w/w to go ahead, and makes the *worker* INLINEABLE
instead, so it can later be specialised.
However, that doesn't completely solve the problem, because the dictionary
argument (which the specialiser treats specially) may be strict and
hence unpacked by w/w, so now the worker won't be specilialised after all.
Solution: never unpack dictionary arguments, which is done by the isClassTyCon
test in WwLib.deepSplitProductType_maybe
|
|
|
|
| |
Signed-off-by: Austin Seipp <austin@well-typed.com>
|
|
|
|
| |
Signed-off-by: Austin Seipp <austin@well-typed.com>
|
|
|
|
|
|
|
|
|
| |
This is a tricky case exposed by Trac #9254. I'm surprised it hasn't
shown up before, because it's happens when you use unsafePerformIO in
the right way.
Anyway, fixed now. See Note [Analysing with absent demand]
in Demand.lhs
|
|
|
|
|
|
|
|
|
| |
In a special case for trivial RHSs (see DmdAnal.unpackTrivial),
I'd forgotten to include a demand for the RHS itself.
See Note [Remember to demand the function itself].
Thanks to David Terei for guiding me to the bug,
at PLDI in Edinburgh.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In some cases, the layout of the LANGUAGE/OPTIONS_GHC lines has been
reorganized, while following the convention, to
- place `{-# LANGUAGE #-}` pragmas at the top of the source file, before
any `{-# OPTIONS_GHC #-}`-lines.
- Moreover, if the list of language extensions fit into a single
`{-# LANGUAGE ... -#}`-line (shorter than 80 characters), keep it on one
line. Otherwise split into `{-# LANGUAGE ... -#}`-lines for each
individual language extension. In both cases, try to keep the
enumeration alphabetically ordered.
(The latter layout is preferable as it's more diff-friendly)
While at it, this also replaces obsolete `{-# OPTIONS ... #-}` pragma
occurences by `{-# OPTIONS_GHC ... #-}` pragmas.
|
|
|
|
|
|
|
|
| |
Previously we always printed qualified names, but that makes a lot of debug or
warning output very verbose. So now we only print qualified names with -dppr-debug.
Civilised output (from pukka error messages, with the environment available) is
unaffected
|
|
|
|
|
|
|
| |
I don't think there should be any change in behaviour, but
the code is clearer now. Function checkSize is elimiated
in favour of doing those checks before (rather than after)
splitFun/splitThunk.
|
|
|
|
|
|
|
|
|
|
| |
See Note [Demand analysis for trivial right-hand sides] in DmdAnal.
This allows a function with arity 2 to have a DmdSig with 3 args;
which in turn had a knock-on effect, which showed up in the test for
Trac #8963.
In fact it seems entirely reasonable, so this patch removes the
WARN and CoreLint checks that were complaining.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Because of GADTs and casts we were getting binders whose
demand annotation was more deeply nested than made sense
for its type.
See Note [Trimming a demand to a type], in Demand.lhs,
which I reproduce here:
Note [Trimming a demand to a type]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Consider this:
f :: a -> Bool
f x = case ... of
A g1 -> case (x |> g1) of (p,q) -> ...
B -> error "urk"
where A,B are the constructors of a GADT. We'll get a U(U,U) demand
on x from the A branch, but that's a stupid demand for x itself, which
has type 'a'. Indeed we get ASSERTs going off (notably in
splitUseProdDmd, Trac #8569).
Bottom line: we really don't want to have a binder whose demand is more
deeply-nested than its type. There are various ways to tackle this.
When processing (x |> g1), we could "trim" the incoming demand U(U,U)
to match x's type. But I'm currently doing so just at the moment when
we pin a demand on a binder, in DmdAnal.findBndrDmd.
|
| |
|
|
|
|
|
|
| |
the ConTag may be out of range (e.g. if the type constructor is imported
via SOURCE and we don't know any of its data constructors); just return
Nothing without complaining in that case. This fixes #8743.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I did some refactoring of the demand analyser, because I was smelling
some minor code smell. Most of my changes I had to undo, though,
adding notes and testcases on why the existing code was correct after
all.
Especially the semantics of the DmdResult is confusing, as it differs in
a DmdType and a StrictSig.
I got to imrpove the readability of the code for lubDmdType, though.
Also, dmdAnalRhs was a bit fishy in how it removed the demand on
further arguments of the body, but used the DmdResult. This would be
wrong if a body would return a demand type of "<L>m" (which currently
does not happen). This is now treated better in removeDmdTyArgs.
|
|
|
|
| |
by passing the FamInstEnvs all the way down. This closes #7619.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Instead of first checking whether splitting is useful, and then firing
up the worker-wrapper-machinery, which will do the same checks again, we
now simply generate a worker and wrapper, and while doing so keep track
of whether what we did was in any way useful.
So now there is only one place left where we decide whether we want to
do w/w, and that place has access to more information, in particular the
actual types at hand.
|
|
|
|
|
|
|
| |
these functions were almost equal, and neither validate nor nofib show
any difference replacing one by the other. So lets simplify this.
(This also prepares for a refactoring that will get rid of
worthSplittingArgDmd completely.)
|
|
|
|
|
| |
by only passing the demand on the free variables, and whether the
argument (resp. scrunitee) may or will diverge.
|
| |
|
|
|
|
|
| |
this is a small-step-refactoring patch and not very interesting on its
own.
|
| |
|
| |
|
|
|
|
| |
by adding Notes and using easier to understand combinators.
|