| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
| |
The testsuite output now contains diagnostic codes, so many tests need
to be updated at once.
We decided it was best to keep the diagnostic codes in the testsuite
output, so that contributors don't inadvertently make changes to the
diagnostic codes.
|
| |
|
|
|
|
|
| |
This patch improves the uniformity of error message formatting by
printing constraints in quotes, as we do for types.
Fix #21167
|
| |
|
|
|
|
|
|
|
|
|
| |
Note [Tidying multiple names at once] indicates that if multiple
variables have the same name then we shouldn't prioritise one of them
and instead rename them all to a1, a2, a3... etc
This patch implements that change, some error message changes as
expected.
Closes #20932
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch redesigns the flattener to simplify type family applications
directly instead of using flattening meta-variables and skolems. The key new
innovation is the CanEqLHS type and the new CEqCan constraint (Ct). A CanEqLHS
is either a type variable or exactly-saturated type family application; either
can now be rewritten using a CEqCan constraint in the inert set.
Because the flattener no longer reduces all type family applications to
variables, there was some performance degradation if a lengthy type family
application is now flattened over and over (not making progress). To
compensate, this patch contains some extra optimizations in the flattener,
leading to a number of performance improvements.
Close #18875.
Close #18910.
There are many extra parts of the compiler that had to be affected in writing
this patch:
* The family-application cache (formerly the flat-cache) sometimes stores
coercions built from Given inerts. When these inerts get kicked out, we must
kick out from the cache as well. (This was, I believe, true previously, but
somehow never caused trouble.) Kicking out from the cache requires adding a
filterTM function to TrieMap.
* This patch obviates the need to distinguish "blocking" coercion holes from
non-blocking ones (which, previously, arose from CFunEqCans). There is thus
some simplification around coercion holes.
* Extra commentary throughout parts of the code I read through, to preserve
the knowledge I gained while working.
* A change in the pure unifier around unifying skolems with other types.
Unifying a skolem now leads to SurelyApart, not MaybeApart, as documented
in Note [Binding when looking up instances] in GHC.Core.InstEnv.
* Some more use of MCoercion where appropriate.
* Previously, class-instance lookup automatically noticed that e.g. C Int was
a "unifier" to a target [W] C (F Bool), because the F Bool was flattened to
a variable. Now, a little more care must be taken around checking for
unifying instances.
* Previously, tcSplitTyConApp_maybe would split (Eq a => a). This is silly,
because (=>) is not a tycon in Haskell. Fixed now, but there are some
knock-on changes in e.g. TrieMap code and in the canonicaliser.
* New function anyFreeVarsOf{Type,Co} to check whether a free variable
satisfies a certain predicate.
* Type synonyms now remember whether or not they are "forgetful"; a forgetful
synonym drops at least one argument. This is useful when flattening; see
flattenView.
* The pattern-match completeness checker invokes the solver. This invocation
might need to look through newtypes when checking representational equality.
Thus, the desugarer needs to keep track of the in-scope variables to know
what newtype constructors are in scope. I bet this bug was around before but
never noticed.
* Extra-constraints wildcards are no longer simplified before printing.
See Note [Do not simplify ConstraintHoles] in GHC.Tc.Solver.
* Whether or not there are Given equalities has become slightly subtler.
See the new HasGivenEqs datatype.
* Note [Type variable cycles in Givens] in GHC.Tc.Solver.Canonical
explains a significant new wrinkle in the new approach.
* See Note [What might match later?] in GHC.Tc.Solver.Interact, which
explains the fix to #18910.
* The inert_count field of InertCans wasn't actually used, so I removed
it.
Though I (Richard) did the implementation, Simon PJ was very involved
in design and review.
This updates the Haddock submodule to avoid #18932 by adding
a type signature.
-------------------------
Metric Decrease:
T12227
T5030
T9872a
T9872b
T9872c
Metric Increase:
T9872d
-------------------------
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Both `bindLHsTyVarBndrs` and `bindHsQTyVars` take two separate
`Maybe` arguments, which I find terribly confusing. Thankfully, it's
possible to remove one `Maybe` argument from each of these functions,
which this patch accomplishes:
* `bindHsQTyVars` takes a `Maybe SDoc` argument, which is `Just` if
GHC should warn about any of the quantified type variables going
unused. However, every call site uses `Nothing` in practice. This
makes sense, since it doesn't really make sense to warn about
unused type variables bound by an `LHsQTyVars`. For instance, you
wouldn't warn about the `a` in `data Proxy a = Proxy` going unused.
As a result, I simply remove this `Maybe SDoc` argument altogether.
* `bindLHsTyVarBndrs` also takes a `Maybe SDoc` argument for the same
reasons that `bindHsQTyVars` took one. To make things more
confusing, however, `bindLHsTyVarBndrs` also takes a separate
`HsDocContext` argument, which is pretty-printed (to an `SDoc`) in
warnings and error messages.
In practice, the `Maybe SDoc` and the `HsDocContext` often contain
the same text. See the call sites for `bindLHsTyVarBndrs` in
`rnFamInstEqn` and `rnConDecl`, for instance. There are only a
handful of call sites where the text differs between the
`Maybe SDoc` and `HsDocContext` arguments:
* In `rnHsRuleDecl`, where the `Maybe SDoc` says "`In the rule`"
and the `HsDocContext` says "`In the transformation rule`".
* In `rnHsTyKi`/`rn_ty`, where the `Maybe SDoc` says
"`In the type`" but the `HsDocContext` is inhereted from the
surrounding context (e.g., if `rnHsTyKi` were called on a
top-level type signature, the `HsDocContext` would be
"`In the type signature`" instead)
In both cases, warnings/error messages arguably _improve_ by
unifying making the `Maybe SDoc`'s text match that of the
`HsDocContext`. As a result, I decided to remove the `Maybe SDoc`
argument to `bindLHsTyVarBndrs` entirely and simply reuse the text
from the `HsDocContext`. (I decided to change the phrase
"transformation rule" to "rewrite rule" while I was in the area.)
The `Maybe SDoc` argument has one other purpose: signaling when to
emit "`Unused quantified type variable`" warnings. To recover this
functionality, I replaced the `Maybe SDoc` argument with a
boolean-like `WarnUnusedForalls` argument. The only
`bindLHsTyVarBndrs` call site that chooses _not_ to emit these
warnings in `bindHsQTyVars`.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch implements eager instantiation, a small but critical change
to the type inference engine, #17173. The main change is this:
When inferring types, always return an instantiated type
(for now, deeply instantiated; in future shallowly instantiated)
There is more discussion in
https://www.tweag.io/posts/2020-04-02-lazy-eager-instantiation.html
There is quite a bit of refactoring in this patch:
* The ir_inst field of GHC.Tc.Utils.TcType.InferResultk
has entirely gone. So tcInferInst and tcInferNoInst have collapsed
into tcInfer.
* Type inference of applications, via tcInferApp and
tcInferAppHead, are substantially refactored, preparing
the way for Quick Look impredicativity.
* New pure function GHC.Tc.Gen.Expr.collectHsArgs and applyHsArgs
are beatifully dual. We can see the zipper!
* GHC.Tc.Gen.Expr.tcArgs is now much nicer; no longer needs to return
a wrapper
* In HsExpr, HsTypeApp now contains the the actual type argument,
and is used in desugaring, rather than putting it in a mysterious
wrapper.
* I struggled a bit with good error reporting in
Unify.matchActualFunTysPart. It's a little bit simpler than before,
but still not great.
Some smaller things
* Rename tcPolyExpr --> tcCheckExpr
tcMonoExpr --> tcLExpr
* tcPatSig moves from GHC.Tc.Gen.HsType to GHC.Tc.Gen.Pat
Metric Decrease:
T9961
Reduction of 1.6% in comiler allocation on T9961, I think.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
When GHC reports that it cannot solve a constraint in error
messages, it often reports what given constraints it has in scope.
Unfortunately, sometimes redundant constraints (like `* ~ *`, from
#15361) can sneak in. The fix is simple: blast away these redundant
constraints using `mkMinimalBySCs`.
Test Plan: make test TEST=T15361
Reviewers: simonpj, bgamari
Subscribers: rwbarton, thomie, carter
GHC Trac Issues: #15361
Differential Revision: https://phabricator.haskell.org/D5002
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Previously, GHC would always raise the possibility that a
type family might not be injective in certain error messages, even if
that type family actually //was// injective. Fix this by actually
checking for a type family's lack of injectivity before emitting
such an error message.
Test Plan: ./validate
Reviewers: goldfire, austin, bgamari, simonpj
Reviewed By: simonpj
Subscribers: simonpj, rwbarton, thomie
GHC Trac Issues: #14369
Differential Revision: https://phabricator.haskell.org/D4106
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch takes further my refactoring of the constraint
solver, which I've been doing over the last couple of months
in consultation with Richard.
It fixes a number of tricky bugs that made the constraint
solver actually go into a loop, including
Trac #12526
Trac #12444
Trac #12538
The main changes are these
* Flatten unification variables (fmvs/fuvs) appear on the LHS
of a tvar/tyvar equality; thus
fmv ~ alpha
and not
alpha ~ fmv
See Note [Put flatten unification variables on the left]
in TcUnify. This is implemented by TcUnify.swapOverTyVars.
* Don't reduce a "loopy" CFunEqCan where the fsk appears on
the LHS:
F t1 .. tn ~ fsk
where 'fsk' is free in t1..tn.
See Note [FunEq occurs-check principle] in TcInteract
This neatly stops some infinite loops that people reported;
and it allows us to delete some crufty code in reduce_top_fun_eq.
And it appears to be no loss whatsoever.
As well as fixing loops, ContextStack2 and T5837 both terminate
when they didn't before.
* Previously we generated "derived shadow" constraints from
Wanteds, but we could (and sometimes did; Trac #xxxx) repeatedly
generate a derived shadow from the same Wanted.
A big change in this patch is to have two kinds of Wanteds:
[WD] behaves like a pair of a Wanted and a Derived
[W] behaves like a Wanted only
See CtFlavour and ShadowInfo in TcRnTypes, and the ctev_nosh
field of a Wanted.
This turned out to be a lot simpler. A [WD] gets split into a
[W] and a [D] in TcSMonad.maybeEmitShaodow.
See TcSMonad Note [The improvement story and derived shadows]
* Rather than have a separate inert_model in the InertCans, I've
put the derived equalities back into inert_eqs. We weren't
gaining anything from a separate field.
* Previously we had a mode for the constraint solver in which it
would more aggressively solve Derived constraints; it was used
for simplifying the context of a 'deriving' clause, or a 'default'
delcaration, for example.
But the complexity wasn't worth it; now I just make proper Wanted
constraints. See TcMType.cloneWC
* Don't generate injectivity improvement for Givens; see
Note [No FunEq improvement for Givens] in TcInteract
* solveSimpleWanteds leaves the insolubles in-place rather than
returning them. Simpler.
I also did lots of work on comments, including fixing Trac #12821.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
foldUFM introduces unnecessary non-determinism that actually
leads to different generated code as explained in
Note [TrieMap determinism].
As we're switching from UniqFM to UniqDFM here you might be
concerned about performance. There's nothing that ./validate
detects. nofib reports no change in Compile Allocations, but
Compile Time got better on some tests and worse on some,
yielding this summary:
-1 s.d. ----- -3.8%
+1 s.d. ----- +5.4%
Average ----- +0.7%
This is not a fair comparison as the order of Uniques
changes what GHC is actually doing. One benefit from making
this deterministic is also that it will make the
performance results more stable.
Full nofib results: P108
Test Plan: ./validate, nofib
Reviewers: goldfire, simonpj, simonmar, austin, bgamari
Reviewed By: simonpj
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D2169
GHC Trac Issues: #4012
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
varSetElemsWellScoped introduces unnecessary non-determinism in
inferred type signatures.
Removing this instance required changing the representation of
TcDepVars to use deterministic sets.
This is the last occurence of varSetElemsWellScoped, allowing me to
finally remove it.
Test Plan:
./validate
I will update the expected outputs when commiting, some reordering
of type variables in types is expected.
Reviewers: goldfire, simonpj, austin, bgamari
Reviewed By: simonpj
Subscribers: thomie, simonmar
Differential Revision: https://phabricator.haskell.org/D2135
GHC Trac Issues: #4012
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch fixes Trac #11523.
* The basic problem was that TcRnTypes.superClassesMightHelp was
returning True of a Derived constraint, and that led to us
expanding Given superclasses, which produced the same Derived
constraint again, and so on infinitely. We really want to do
this only if there are unsolve /Wanted/ contraints!
* On the way I made TcSMonad.getUnsolvedInerts a bit more
discriminating about which Derived equalities it returns;
see Note [Unsolved Derived equalities] in TcSMonad
* Lots of new comments in TcSMonad.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This re-working of the typechecker algorithm is based on
the paper "Visible type application", by Richard Eisenberg,
Stephanie Weirich, and Hamidhasan Ahmed, to be published at
ESOP'16.
This patch introduces -XTypeApplications, which allows users
to say, for example `id @Int`, which has type `Int -> Int`. See
the changes to the user manual for details.
This patch addresses tickets #10619, #5296, #10589.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch fulfils the request in Trac #11067, #10318, and #10592,
by lifting the conservative restrictions on superclass constraints.
These restrictions are there (and have been since Haskell was born) to
ensure that the transitive superclasses of a class constraint is a finite
set. However (a) this restriction is conservative, and can be annoying
when there really is no recursion, and (b) sometimes genuinely recursive
superclasses are useful (see the tickets).
Dimitrios and I worked out that there is actually a relatively simple way
to do the job. It’s described in some detail in
Note [The superclass story] in TcCanonical
Note [Expanding superclasses] in TcType
In brief, the idea is to expand superclasses only finitely, but to
iterate (using a loop that already existed) if there are more
superclasses to explore.
Other small things
- I improved grouping of error messages a bit in TcErrors
- I re-centred the haddock.compiler test, which was at 9.8%
above the norm, and which this patch pushed slightly over
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This puts the "Relevant bindings" section at the end.
It uses a TcErrors.Report Monoid to divide messages by importance and
then mappends them together. This is not the most efficient way since
there are various intermediate Reports and list appends, but it probably
doesn't matter since error messages shouldn't get that large, and are
usually prepended. In practice, everything is `important` except
`relevantBindings`, which is `supplementary`.
ErrMsg's errMsgShortDoc and errMsgExtraInfo were extracted into ErrDoc,
which has important, context, and suppelementary fields. Each of those
three sections is marked with a bullet character, '•' on unicode
terminals and '*' on ascii terminals. Since this breaks tons of tests,
I also modified testlib.normalise_errmsg to strip out '•'s.
--- Additional notes:
To avoid prepending * to an empty doc, I needed to filter empty docs.
This seemed less error-prone than trying to modify everyone who produces
SDoc to instead produce Maybe SDoc. So I added `Outputable.isEmpty`.
Unfortunately it needs a DynFlags, which is kind of bogus, but otherwise
I think I'd need another Empty case for SDoc, and then it couldn't be a
newtype any more.
ErrMsg's errMsgShortString is only used by the Show instance, which is
in turn only used by Show HscTypes.SourceError, which is in turn only
needed for the Exception instance. So it's probably possible to get rid
of errMsgShortString, but that would a be an unrelated cleanup.
Fixes #11014.
Test Plan: see above
Reviewers: austin, simonpj, thomie, bgamari
Reviewed By: thomie, bgamari
Subscribers: simonpj, nomeata, thomie
Differential Revision: https://phabricator.haskell.org/D1427
GHC Trac Issues: #11014
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I just didn't think it was buying enough for all the cruft it caused.
We can put some back if people start complaining about poor error
messages. I forget quite how I tripped over this but I got sucked in.
* Lots of tidying up in TcErrors
* Rename pprArisingAt to pprCtLoc, by analogy with pprCtOrigin
* Remove CoercibleOrigin data constructor from CtOrigin
* Make relevantBindings return a Ct with a zonked
and tidied CtOrigin
* Add to TcRnTypes
ctOrigin :: Ct -> CtOrigin
ctEvOrigin :: CtEvidence -> CtOrigin
setCtLoc :: Ct -> CtLoc -> Ct
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I wasn't very happy with my fix to Trac #10009. This is much better.
The main idea is that the inert set now contains a "model", which
embodies *all* the (nominal) equalities that we know about, with
a view to exposing unifications. This requires a lot fewer iterations
of the solver than before.
There are extensive comments in
TcSMonad: Note [inert_model: the inert model]
Note [Adding an inert canonical constraint the InertCans]
The big changes are
* New inert_model field in InertCans
* Functions addInertEq, addInertCan deal with adding a
constraint, maintaining the model
* A nice improvement is that unification variables can
unify with fmvs, so that from, say alpha ~ fmv
we get alpha := fmv
See Note [Orientation of equalities with fmvs] in TcFlatten
It's still not perfect, as the Note explains
New flag -fconstraint-solver-iterations=n, allows us to control
the number of constraint solver iterations, and in particular
will flag up when it's more than a small number.
Performance is generally slightly better:
T5837 is a lot better for some reason.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The main point is described in Note [Solve order for RULES].
I'm not sure if the potential bug described there could actually
happen, but I bet it could. Anyway, this patch explicitly solves
LHS constraints and *then* RHS constraints (see the Note).
I also moved simplifyRule from TcSimplify (a large module) to
TcRules (a small one), which brings related code together.
It did mean I had to export runTcS from TcSimplify, but I think
that's a price worth paying.
|
| |
|
|
|
|
|
|
|
|
| |
The main change is in TypeRep.pprTheta, so we print
Eq a
for a singleton, but
(Eq a, Show a)
for multiple constraints.
There are lots of trivial knock-on changes to error messages
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
order
Trac #9872 showed the importance of processing goals in depth-first, so that
we do not build up a huge pool of suspended function calls, waiting for their
children to fire. There is a detailed explanation in
Note [The flattening work list]
in TcFlatten
The effect for Trac #9872 (slow1.hs) is dramatic. We go from too long
to wait down to 28Gbyte allocation. GHC 7.8.3 did 116Gbyte allocation!
|
| | |
|
| |
|
|
|
|
|
| |
This matches GCC's choice of Unicode quotation marks (i.e. U+2018 and U+2019)
and therefore looks more familiar on the console. This addresses #2507.
Signed-off-by: Herbert Valerio Riedel <hvr@gnu.org>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Almost all are re-orderings of relevant-binding output
Relevant bindings include
+ m :: Map (a, b) elt (bound at T3169.hs:12:17)
+ b :: b (bound at T3169.hs:12:13)
lookup :: (a, b) -> Map (a, b) elt -> Maybe elt
(bound at T3169.hs:12:3)
- b :: b (bound at T3169.hs:12:13)
- m :: Map (a, b) elt (bound at T3169.hs:12:17)
|
| | |
|
| | |
|
| |
|
|
|
|
| |
Notably
* Showing relevant bindings
* Not suggesting add instance (Num T); see Trac #7222
|
| |
|
