| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
Just better layout in output for the user
|
| |
|
|
|
|
|
|
|
|
|
| |
Trac #14394 showed that it's possible to get redundant
constraints in the inferred provided constraints of a pattern
synonym. This patch removes the redundancy with mkMinimalBySCs.
To do this I had to generalise the type of mkMinimalBySCs slightly.
And, to reduce confusing reversal, I made it stable: it now returns
its result in the same order as its input. That led to a raft of
error message wibbles, mostly for the better.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
TcSimplify.decideQuantification was doing the Wrong Thing when
"growing" the type variables to quantify over. We were trying to do
this on a tyvar set where we'd split off the dependent type varaibles;
and we just got it wrong. A kind variable wasn't being generalised
properly, with confusing knock on consequences.
All this led to Trac #13371 and Trac #13393.
This commit tidies it all up:
* The type TcDepVars is renamed as CandidateQTvs;
and splitDepVarsOfType to candidateQTyVarsOfType
* The code in TcSimplify.decideQuantification is simpler.
It no longer does the tricky "grow" stuff over TcDepVars.
Instead it use ordinary VarSets (thereby eliminating the
nasty growThetaTyVarsDSet) and uses that to filter the
result of candidateQTyVarsOfType.
* I documented that candidateQTyVarsOfType returns the type
variables in a good order in which to quantify, and rewrote
it to use an accumulator pattern, so that we would predicatably
get left-to-right ordering.
In doing all this I also made UniqDFM behave a little more nicely:
* When inserting an element that is there already, keep the old tag,
while still overwriting with the new value.
* This means that when doing udfmToList we get back elements in the
order they were originally inserted, rather than in reverse order.
It's not a big deal, but in a subsequent commit I use it to improve
the order of type variables in inferred types.
All this led to a lot of error message wibbles:
- changing the order of quantified variables
- changing the order in which instances are listed in GHCi
- changing the tidying of variables in typechecker erors
There's a submodule update for 'array' because one of its tests
has an error-message change.
I may not have associated all of them with the correct commit.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch does a raft of useful tidy-ups in the type checker.
I've been meaning to do this for some time, and finally made
time to do it en route to ICFP.
1. Modify TcType.ExpType to make a distinct data type,
InferResult for the Infer case, and consequential
refactoring.
2. Define a new function TcUnify.fillInferResult, to fill in
an InferResult. It uses TcMType.promoteTcType to promote
the type to the level of the InferResult.
See TcMType Note [Promoting a type]
This refactoring is in preparation for an improvement
to typechecking pattern bindings, coming next.
I flirted with an elaborate scheme to give better
higher rank inference, but it was just too complicated.
See TcMType Note [Promotion and higher rank types]
3. Add to InferResult a new field ir_inst :: Bool to say
whether or not the type used to fill in the
InferResult should be deeply instantiated. See
TcUnify Note [Deep instantiation of InferResult].
4. Add a TcLevel to SkolemTvs. This will be useful generally
- it's a fast way to see if the type
variable escapes when floating (not used yet)
- it provides a good consistency check when updating a
unification variable (TcMType.writeMetaTyVarRef, the
level_check_ok check)
I originally had another reason (related to the flirting
in (2), but I left it in because it seems like a step in
the right direction.
5. Reduce and simplify the plethora of uExpType,
tcSubType and related functions in TcUnify. It was
such an opaque mess and it's still not great, but it's
better.
6. Simplify the uo_expected field of TypeEqOrigin. Richard
had generatlised it to a ExpType, but it was almost always
a Check type. Now it's back to being a plain TcType which
is much, much easier.
7. Improve error messages by refraining from skolemisation when
it's clear that there's an error: see
TcUnify Note [Don't skolemise unnecessarily]
8. Type.isPiTy and isForAllTy seem to be missing a coreView check,
so I added it
9. Kill off tcs_used_tcvs. Its purpose is to track the
givens used by wanted constraints. For dictionaries etc
we do that via the free vars of the /bindings/ in the
implication constraint ic_binds. But for coercions we
just do update-in-place in the type, rather than
generating a binding. So we need something analogous to
bindings, to track what coercions we have added.
That was the purpose of tcs_used_tcvs. But it only
worked for a /single/ iteration, whereas we may have
multiple iterations of solving an implication. Look
at (the old) 'setImplicationStatus'. If the constraint
is unsolved, it just drops the used_tvs on the floor.
If it becomes solved next time round, we'll pick up
coercions used in that round, but ignore ones used in
the first round.
There was an outright bug. Result = (potentialy) bogus
unused-constraint errors. Constructing a case where this
actually happens seems quite trick so I did not do so.
Solution: expand EvBindsVar to include the (free vars of
the) coercions, so that the coercions are tracked in
essentially the same way as the bindings.
This turned out to be much simpler. Less code, more
correct.
10. Make the ic_binds field in an implication have type
ic_binds :: EvBindsVar
instead of (as previously)
ic_binds :: Maybe EvBindsVar
This is notably simpler, and faster to use -- less
testing of the Maybe. But in the occaional situation
where we don't have anywhere to put the bindings, the
belt-and-braces error check is lost. So I put it back
as an ASSERT in 'setImplicationStatus' (see the use of
'termEvidenceAllowed')
All these changes led to quite bit of error message wibbling
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before this patch, following the TypeInType innovations,
each TyCon had two lists:
- tyConBinders :: [TyBinder]
- tyConTyVars :: [TyVar]
They were in 1-1 correspondence and contained
overlapping information. More broadly, there were many
places where we had to pass around this pair of lists,
instead of a single list.
This commit tidies all that up, by having just one list of
binders in a TyCon:
- tyConBinders :: [TyConBinder]
The new data types look like this:
Var.hs:
data TyVarBndr tyvar vis = TvBndr tyvar vis
data VisibilityFlag = Visible | Specified | Invisible
type TyVarBinder = TyVarBndr TyVar VisibilityFlag
TyCon.hs:
type TyConBinder = TyVarBndr TyVar TyConBndrVis
data TyConBndrVis
= NamedTCB VisibilityFlag
| AnonTCB
TyCoRep.hs:
data TyBinder
= Named TyVarBinder
| Anon Type
Note that Var.TyVarBdr has moved from TyCoRep and has been
made polymorphic in the tyvar and visiblity fields:
type TyVarBinder = TyVarBndr TyVar VisibilityFlag
-- Used in ForAllTy
type TyConBinder = TyVarBndr TyVar TyConBndrVis
-- Used in TyCon
type IfaceForAllBndr = TyVarBndr IfaceTvBndr VisibilityFlag
type IfaceTyConBinder = TyVarBndr IfaceTvBndr TyConBndrVis
-- Ditto, in interface files
There are a zillion knock-on changes, but everything
arises from these types. It was a bit fiddly to get the
module loops to work out right!
Some smaller points
~~~~~~~~~~~~~~~~~~~
* Nice new functions
TysPrim.mkTemplateKiTyVars
TysPrim.mkTemplateTyConBinders
which help you make the tyvar binders for dependently-typed
TyCons. See comments with their definition.
* The change showed up a bug in TcGenGenerics.tc_mkRepTy, where the code
was making an assumption about the order of the kind variables in the
kind of GHC.Generics.(:.:). I fixed this; see TcGenGenerics.mkComp.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
In particular, this allows correct tracking of specified/invisible
for variables in Haskell98 data constructors and in pattern synonyms.
GADT-syntax constructors are harder, and are left until #11721.
This was all inspired by Simon's comments to my fix for #11512,
which this subsumes.
Test case: ghci/scripts/TypeAppData
[skip ci] (The test case fails because of an unrelated problem
fixed in the next commit.)
|
|
|
Now the existentially quantified type variables are printed
at the correct location when printing a pattern synonym type
from an `IfacePatSyn`. The function `pprIfaceContextMaybe`
has been removed as it is no longer needed.
Fixes #11524.
Reviewers: austin, goldfire, thomie, bgamari, mpickering
Reviewed By: bgamari
Differential Revision: https://phabricator.haskell.org/D1958
GHC Trac Issues: #11524
|
