| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
| |
This fixes #22065. We were failing to retain a quantifier that
was mentioned in the kind of another retained quantifier.
Easy to fix.
|
| |
|
|
| |
Happily, this has been fixed since 9.2.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The main fix for #21667 is the new call to tcInstTypeBnders
in tcHsPartialSigType. It was really a simple omission before.
I also moved the decision about whether we need to apply the
Monomorphism Restriction, from `decideGeneralisationPlan` to
`tcPolyInfer`. That removes a flag from the InferGen constructor,
which is good.
But more importantly, it allows the new function,
checkMonomorphismRestriction
called from `tcPolyInfer`, to "see" the `Types` involved rather than
the `HsTypes`. And that in turn matters because we invoke the MR for
partial signatures if none of the partial signatures in the group have
any overloading context; and we can't answer that question for HsTypes.
See Note [Partial type signatures and the monomorphism restriction]
in GHC.Tc.Gen.Bind.
This latter is really a pre-existing bug.
|
| |
|
|
|
|
| |
Our error reporting in generated code (via desugaring before
typechecking) only worked when the generated code was just a simple
call. This commit makes it work in nested cases.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The "candidates" passed to decideMonoTyVars can contain coercion holes.
This is because we might well decide to quantify over some unsolved
equality constraints, as long as they are not definitely insoluble.
In that situation, decideMonoTyVars was passing a set of type variables
that was not closed over kinds to closeWrtFunDeps, which was tripping
up an assertion failure.
Fixes #21404
|
| |
|
|
|
|
|
|
|
|
| |
* Users can define their own (~) type operator
* Haddock can display documentation for the built-in (~)
* New transitional warnings implemented:
-Wtype-equality-out-of-scope
-Wtype-equality-requires-operators
Updates the haddock submodule.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The code in tcAnonWildCardOcc assumed that it could never encounter
anonymous wildcards in illegal positions, because the renamer would
have ruled them out. However, it's possible to sneak past the checks
in the renamer by using Template Haskell. It isn't possible to simply
pass on additional information when renaming Template Haskell
brackets, because we don't know in advance in what context the bracket
will be spliced in (see test case T15433b). So we accept that we might
encounter these bogus wildcards in the typechecker and throw the
appropriate error.
This patch also migrates the error messages for illegal wildcards in
types to use the diagnostic infrastructure.
Fixes #15433
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Co-authored by: Sam Derbyshire
Previously, GHC had three flavours of constraint:
Wanted, Given, and Derived. This removes Derived constraints.
Though serving a number of purposes, the most important role
of Derived constraints was to enable better error messages.
This job has been taken over by the new RewriterSets, as explained
in Note [Wanteds rewrite wanteds] in GHC.Tc.Types.Constraint.
Other knock-on effects:
- Various new Notes as I learned about under-described bits of GHC
- A reshuffling around the AST for implicit-parameter bindings,
with better integration with TTG.
- Various improvements around fundeps. These were caused by the
fact that, previously, fundep constraints were all Derived,
and Derived constraints would get dropped. Thus, an unsolved
Derived didn't stop compilation. Without Derived, this is no
longer possible, and so we have to be considerably more careful
around fundeps.
- A nice little refactoring in GHC.Tc.Errors to center the work
on a new datatype called ErrorItem. Constraints are converted
into ErrorItems at the start of processing, and this allows for
a little preprocessing before the main classification.
- This commit also cleans up the behavior in generalisation around
functional dependencies. Now, if a variable is determined by
functional dependencies, it will not be quantified. This change
is user facing, but it should trim down GHC's strange behavior
around fundeps.
- Previously, reportWanteds did quite a bit of work, even on an empty
WantedConstraints. This commit adds a fast path.
- Now, GHC will unconditionally re-simplify constraints during
quantification. See Note [Unconditionally resimplify constraints when
quantifying], in GHC.Tc.Solver.
Close #18398.
Close #18406.
Solve the fundep-related non-confluence in #18851.
Close #19131.
Close #19137.
Close #20922.
Close #20668.
Close #19665.
-------------------------
Metric Decrease:
LargeRecord
T9872b
T9872b_defer
T9872d
TcPlugin_RewritePerf
-------------------------
|
| |
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The main purpose of this patch is to attach a SkolemInfo directly to
each SkolemTv. This fixes the large number of bugs which have
accumulated over the years where we failed to report errors due to
having "no skolem info" for particular type variables. Now the origin of
each type varible is stored on the type variable we can always report
accurately where it cames from.
Fixes #20969 #20732 #20680 #19482 #20232 #19752 #10946
#19760 #20063 #13499 #14040
The main changes of this patch are:
* SkolemTv now contains a SkolemInfo field which tells us how the
SkolemTv was created. Used when reporting errors.
* Enforce invariants relating the SkolemInfoAnon and level of an implication (ic_info, ic_tclvl)
to the SkolemInfo and level of the type variables in ic_skols.
* All ic_skols are TcTyVars -- Check is currently disabled
* All ic_skols are SkolemTv
* The tv_lvl of the ic_skols agrees with the ic_tclvl
* The ic_info agrees with the SkolInfo of the implication.
These invariants are checked by a debug compiler by
checkImplicationInvariants.
* Completely refactor kcCheckDeclHeader_sig which kept
doing my head in. Plus, it wasn't right because it wasn't skolemising
the binders as it decomposed the kind signature.
The new story is described in Note [kcCheckDeclHeader_sig]. The code
is considerably shorter than before (roughly 240 lines turns into 150
lines).
It still has the same awkward complexity around computing arity as
before, but that is a language design issue.
See Note [Arity inference in kcCheckDeclHeader_sig]
* I added new type synonyms MonoTcTyCon and PolyTcTyCon, and used
them to be clear which TcTyCons have "finished" kinds etc, and
which are monomorphic. See Note [TcTyCon, MonoTcTyCon, and PolyTcTyCon]
* I renamed etaExpandAlgTyCon to splitTyConKind, becuase that's a
better name, and it is very useful in kcCheckDeclHeader_sig, where
eta-expansion isn't an issue.
* Kill off the nasty `ClassScopedTvEnv` entirely.
Co-authored-by: Simon Peyton Jones <simon.peytonjones@gmail.com>
|
| |
|
|
|
|
|
|
|
|
|
| |
As #20921 showed, with partial signatures, it is helpful to use the
same algorithm (namely findInferredDiff) for
* picking the constraints to retain for the /group/
in Solver.decideQuantification
* picking the contraints to retain for the /individual function/
in Bind.chooseInferredQuantifiers
This is still regrettably declicate, but it's a step forward.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
When instances overlap, we now include additional information
about why we weren't able to select an instance: perhaps
one instance overlapped another but was not strictly more specific,
so we aren't able to directly choose it.
Fixes #20542
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
There were two problems around `mkDictErr`:
1. An outdated call to `flattenTys` meant that we missed out on some
instances. As we no longer flatten type-family applications,
the logic is obsolete and can be removed.
2. We reported "out of scope" errors in a poly-kinded situation
because `BoxedRep` and `Lifted` were considered out of scope.
We fix this by using `pretendNameIsInScope`.
fixes #20465
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This (big) commit finishes porting the GHC.Tc.Deriv module to support
the new diagnostic infrastructure (#18516) by getting rid of the legacy
calls to `TcRnUnknownMessage`. This work ended up being quite pervasive
and touched not only the Tc.Deriv module but also the Tc.Deriv.Utils and
Tc.Deriv.Generics module, which needed to be adapted to use the new
infrastructure. This also required generalising `Validity`.
More specifically, this is a breakdown of the work done:
* Add and use the TcRnUselessTypeable data constructor
* Add and use TcRnDerivingDefaults data constructor
* Add and use the TcRnNonUnaryTypeclassConstraint data constructor
* Add and use TcRnPartialTypeSignatures
* Add T13324_compile2 test to test another part of the
TcRnPartialTypeSignatures diagnostic
* Add and use TcRnCannotDeriveInstance data constructor, which introduces a
new data constructor to TcRnMessage called TcRnCannotDeriveInstance, which
is further sub-divided to carry a `DeriveInstanceErrReason` which explains
the reason why we couldn't derive a typeclass instance.
* Add DerivErrSafeHaskellGenericInst data constructor to DeriveInstanceErrReason
* Add DerivErrDerivingViaWrongKind and DerivErrNoEtaReduce
* Introduce the SuggestExtensionInOrderTo Hint, which adds (and use) a new
constructor to the hint type `LanguageExtensionHint` called `SuggestExtensionInOrderTo`,
which can be used to give a bit more "firm" recommendations when it's
obvious what the required extension is, like in the case for the
`DerivingStrategies`, which automatically follows from having enabled
both `DeriveAnyClass` and `GeneralizedNewtypeDeriving`.
* Wildcard-free pattern matching in mk_eqn_stock, which removes `_` in
favour of pattern matching explicitly on `CanDeriveAnyClass` and
`NonDerivableClass`, because that determine whether or not we can
suggest to the user `DeriveAnyClass` or not.
|
| |
|
|
|
|
|
|
|
| |
Oleg Grenrus pointed out that `Solo` was missing `Eq`, `Ord`,
`Bounded`, `Enum`, and `Ix` instances, which were all apparently
available for the `OneTuple` type (in the `OneTuple` package).
Though only the first three really seem useful, there's no reason
not to take them all. For `Ix`, `Solo` naturally fills a gap
between `()` and `(,)`.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit modifies interface files so that *only* direct information
about modules and packages is stored in the interface file.
* Only direct module and direct package dependencies are stored in the
interface files.
* Trusted packages are now stored separately as they need to be checked
transitively.
* hs-boot files below the compiled module in the home module are stored
so that eps_is_boot can be calculated in one-shot mode without loading
all interface files in the home package.
* The transitive closure of signatures is stored separately
This is important for two reasons
* Less recompilation is needed, as motivated by #16885, a lot of
redundant compilation was triggered when adding new imports deep in the
module tree as all the parent interface files had to be redundantly
updated.
* Checking an interface file is cheaper because you don't have to
perform a transitive traversal to check the dependencies are up-to-date.
In the code, places where we would have used the transitive closure, we
instead compute the necessary transitive closure. The closure is not
computed very often, was already happening in checkDependencies, and
was already happening in getLinkDeps.
Fixes #16885
-------------------------
Metric Decrease:
MultiLayerModules
T13701
T13719
-------------------------
|
| |
|
|
|
|
|
|
|
|
| |
Fixes #19616.
This commit changes the `GHC.Driver.Errors.handleFlagWarnings` function
to rely on the newly introduced `DiagnosticReason`. This allows us to
correctly pretty-print the flags which triggered some warnings and in
turn remove the cruft around this function (like the extra filtering
and the `shouldPrintWarning` function.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Other than that:
* Fix T16167,json,json2,T7478,T10637 tests to reflect the introduction of
the `MessageClass` type
* Remove `makeIntoWarning`
* Remove `warningsToMessages`
* Refactor GHC.Tc.Errors
1. Refactors GHC.Tc.Errors so that we use `DiagnosticReason` for "choices"
(defer types errors, holes, etc);
2. We get rid of `reportWarning` and `reportError` in favour of a general
`reportDiagnostic`.
* Introduce `DiagnosticReason`, `Severity` is an enum: This big commit makes
`Severity` a simple enumeration, and introduces the concept of `DiagnosticReason`,
which classifies the /reason/ why we are emitting a particular diagnostic.
It also adds a monomorphic `DiagnosticMessage` type which is used for
generic messages.
* The `Severity` is computed (for now) from the reason, statically.
Later improvement will add a `diagReasonSeverity` function to compute
the `Severity` taking `DynFlags` into account.
* Rename `logWarnings` into `logDiagnostics`
* Add note and expand description of the `mkHoleError` function
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Ticket #19364 helpfully points out that we do not currently take
advantage of pushing the result type of an application into the
arguments. This makes error messages notably less good.
The fix is rather easy: move the result-type unification step earlier.
It's even a bit more efficient; in the the checking case we now
do one less zonk.
See Note [Unify with expected type before typechecking arguments]
in GHC.Tc.Gen.App
This change generally improves error messages, but it made one worse:
typecheck/should_fail/T16204c. That led me to the realisation that
a good error can be replaced by a less-good one, which provoked
me to change GHC.Tc.Solver.Interact.inertsCanDischarge. It's
explained in the new Note [Combining equalities]
One other refactoring: I discovered that KindEqOrigin didn't need a
Maybe in its type -- a nice simplification.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This has two fixes:
1. Take TyVarTvs into account in matchableGivens. This
fixes #19106.
2. Don't allow unifying alpha ~ Maybe alpha. This fixes
#19107.
This patch also removes a redundant Note and redirects
references to a better replacement.
Also some refactoring/improvements around the BindFun
in the pure unifier, which now can take the RHS type
into account.
Close #19106.
Close #19107.
Test case: partial-sigs/should_compile/T19106,
typecheck/should_compile/T19107
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch establishes invariant (GivenInv) from GHC.Tc.Utils.TcType
Note [TcLevel invariants]. (GivenInv) says that unification variables
from level 'n' should not appear in the Givens for level 'n'. See
Note [GivenInv] in teh same module.
This invariant was already very nearly true, but a dark corner of
partial type signatures made it false. The patch re-jigs partial type
signatures a bit to avoid the problem, and documents the invariant
much more thorughly
Fixes #18646 along the way: see Note [Extra-constraints wildcards]
in GHC.Tc.Gen.Bind
I also simplified the interface to tcSimplifyInfer slightly, so that
it /emits/ the residual constraint, rather than /returning/ it.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch delivers on #17656, by entirel killing off the complex
floatEqualities mechanism. Previously, floatEqualities would float an
equality out of an implication, so that it could be solved at an outer
level. But now we simply do unification in-place, without floating the
constraint, relying on level numbers to determine untouchability.
There are a number of important new Notes:
* GHC.Tc.Utils.Unify Note [Unification preconditions]
describes the preconditions for unification, including both
skolem-escape and touchability.
* GHC.Tc.Solver.Interact Note [Solve by unification]
describes what we do when we do unify
* GHC.Tc.Solver.Monad Note [The Unification Level Flag]
describes how we control solver iteration under this new scheme
* GHC.Tc.Solver.Monad Note [Tracking Given equalities]
describes how we track when we have Given equalities
* GHC.Tc.Types.Constraint Note [HasGivenEqs]
is a new explanation of the ic_given_eqs field of an implication
A big raft of subtle Notes in Solver, concerning floatEqualities,
disappears.
Main code changes:
* GHC.Tc.Solver.floatEqualities disappears entirely
* GHC.Tc.Solver.Monad: new fields in InertCans, inert_given_eq_lvl
and inert_given_eq, updated by updateGivenEqs
See Note [Tracking Given equalities].
* In exchange for updateGivenEqa, GHC.Tc.Solver.Monad.getHasGivenEqs
is much simpler and more efficient
* I found I could kill of metaTyVarUpdateOK entirely
One test case T14683 showed a 5.1% decrease in compile-time
allocation; and T5631 was down 2.2%. Other changes were small.
Metric Decrease:
T14683
T5631
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
-------------------------
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This refactors the GHC AST to remove `HsImplicitBndrs` and replace it with
`HsOuterTyVarBndrs`, a type which records whether the outermost quantification
in a type is explicit (i.e., with an outermost, invisible `forall`) or
implicit. As a result of this refactoring, it is now evident in the AST where
the `forall`-or-nothing rule applies: it's all the places that use
`HsOuterTyVarBndrs`. See the revamped `Note [forall-or-nothing rule]` in
`GHC.Hs.Type` (previously in `GHC.Rename.HsType`).
Moreover, the places where `ScopedTypeVariables` brings lexically scoped type
variables into scope are a subset of the places that adhere to the
`forall`-or-nothing rule, so this also makes places that interact with
`ScopedTypeVariables` easier to find. See the revamped
`Note [Lexically scoped type variables]` in `GHC.Hs.Type` (previously in
`GHC.Tc.Gen.Sig`).
`HsOuterTyVarBndrs` are used in type signatures (see `HsOuterSigTyVarBndrs`)
and type family equations (see `HsOuterFamEqnTyVarBndrs`). The main difference
between the former and the latter is that the former cares about specificity
but the latter does not.
There are a number of knock-on consequences:
* There is now a dedicated `HsSigType` type, which is the combination of
`HsOuterSigTyVarBndrs` and `HsType`. `LHsSigType` is now an alias for an
`XRec` of `HsSigType`.
* Working out the details led us to a substantial refactoring of
the handling of explicit (user-written) and implicit type-variable
bindings in `GHC.Tc.Gen.HsType`.
Instead of a confusing family of higher order functions, we now
have a local data type, `SkolemInfo`, that controls how these
binders are kind-checked.
It remains very fiddly, not fully satisfying. But it's better
than it was.
Fixes #16762. Bumps the Haddock submodule.
Co-authored-by: Simon Peyton Jones <simonpj@microsoft.com>
Co-authored-by: Richard Eisenberg <rae@richarde.dev>
Co-authored-by: Zubin Duggal <zubin@cmi.ac.in>
|
| |
|
|
|
|
|
|
|
| |
-------------------------
Metric Decrease:
T12425
Metric Increase:
T17516
-------------------------
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch does two things:
* It refactors GHC.Tc.Errors a bit. In debugging Quick Look I was
forced to look in detail at error messages, and ended up doing a bit
of refactoring, esp in mkTyVarEqErr'. It's still quite a mess, but
a bit better, I think.
* It makes a significant improvement to the kind checking of type and
class declarations. Specifically, we now ensure that if kind
checking fails with an unsolved constraint, all the skolems are in
scope. That wasn't the case before, which led to some obscure error
messages; and occasional failures with "no skolem info" (eg #16245).
Both of these, and the main Quick Look patch itself, affect a /lot/ of
error messages, as you can see from the number of files changed. I've
checked them all; I think they are as good or better than before.
Smaller things
* I documented the various instances of VarBndr better.
See Note [The VarBndr tyep and its uses] in GHC.Types.Var
* Renamed GHC.Tc.Solver.simpl_top to simplifyTopWanteds
* A bit of refactoring in bindExplicitTKTele, to avoid the
footwork with Either. Simpler now.
* Move promoteTyVar from GHC.Tc.Solver to GHC.Tc.Utils.TcMType
Fixes #16245 (comment 211369), memorialised as
typecheck/polykinds/T16245a
Also fixes the three bugs in #18640
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There are three problems with the current API:
1. It is hard to properly write instances for ``Quote m => m (TExp a)`` as the type is the composition
of two type constructors. Doing so in your program involves making your own newtype and
doing a lot of wrapping/unwrapping.
For example, if I want to create a language which I can either run immediately or
generate code from I could write the following with the new API. ::
class Lang r where
_int :: Int -> r Int
_if :: r Bool -> r a -> r a -> r a
instance Lang Identity where
_int = Identity
_if (Identity b) (Identity t) (Identity f) = Identity (if b then t else f)
instance Quote m => Lang (Code m) where
_int = liftTyped
_if cb ct cf = [|| if $$cb then $$ct else $$cf ||]
2. When doing code generation it is common to want to store code fragments in
a map. When doing typed code generation, these code fragments contain a
type index so it is desirable to store them in one of the parameterised
map data types such as ``DMap`` from ``dependent-map`` or ``MapF`` from
``parameterized-utils``.
::
compiler :: Env -> AST a -> Code Q a
data AST a where ...
data Ident a = ...
type Env = MapF Ident (Code Q)
newtype Code m a = Code (m (TExp a))
In this example, the ``MapF`` maps an ``Ident String`` directly to a ``Code Q String``.
Using one of these map types currently requires creating your own newtype and constantly
wrapping every quotation and unwrapping it when using a splice. Achievable, but
it creates even more syntactic noise than normal metaprogramming.
3. ``m (TExp a)`` is ugly to read and write, understanding ``Code m a`` is
easier. This is a weak reason but one everyone
can surely agree with.
Updates text submodule.
|
| |
|
|
| |
Fixes #18279. Bumps the `text` submodule.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
* support detection of slow ghc-bignum backend (to replace the detection
of integer-simple use). There are still some test cases that the
native backend doesn't handle efficiently enough.
* remove tests for GMP only functions that have been removed from
ghc-bignum
* fix test results showing dependent packages (e.g. integer-gmp) or
showing suggested instances
* fix test using Integer/Natural API or showing internal names
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch simplifies GHC to use simple subsumption.
Ticket #17775
Implements GHC proposal #287
https://github.com/ghc-proposals/ghc-proposals/blob/master/
proposals/0287-simplify-subsumption.rst
All the motivation is described there; I will not repeat it here.
The implementation payload:
* tcSubType and friends become noticably simpler, because it no
longer uses eta-expansion when checking subsumption.
* No deeplyInstantiate or deeplySkolemise
That in turn means that some tests fail, by design; they can all
be fixed by eta expansion. There is a list of such changes below.
Implementing the patch led me into a variety of sticky corners, so
the patch includes several othe changes, some quite significant:
* I made String wired-in, so that
"foo" :: String rather than
"foo" :: [Char]
This improves error messages, and fixes #15679
* The pattern match checker relies on knowing about in-scope equality
constraints, andd adds them to the desugarer's environment using
addTyCsDs. But the co_fn in a FunBind was missed, and for some reason
simple-subsumption ends up with dictionaries there. So I added a
call to addTyCsDs. This is really part of #18049.
* I moved the ic_telescope field out of Implication and into
ForAllSkol instead. This is a nice win; just expresses the code
much better.
* There was a bug in GHC.Tc.TyCl.Instance.tcDataFamInstHeader.
We called checkDataKindSig inside tc_kind_sig, /before/
solveEqualities and zonking. Obviously wrong, easily fixed.
* solveLocalEqualitiesX: there was a whole mess in here, around
failing fast enough. I discovered a bad latent bug where we
could successfully kind-check a type signature, and use it,
but have unsolved constraints that could fill in coercion
holes in that signature -- aargh.
It's all explained in Note [Failure in local type signatures]
in GHC.Tc.Solver. Much better now.
* I fixed a serious bug in anonymous type holes. IN
f :: Int -> (forall a. a -> _) -> Int
that "_" should be a unification variable at the /outer/
level; it cannot be instantiated to 'a'. This was plain
wrong. New fields mode_lvl and mode_holes in TcTyMode,
and auxiliary data type GHC.Tc.Gen.HsType.HoleMode.
This fixes #16292, but makes no progress towards the more
ambitious #16082
* I got sucked into an enormous refactoring of the reporting of
equality errors in GHC.Tc.Errors, especially in
mkEqErr1
mkTyVarEqErr
misMatchMsg
misMatchMsgOrCND
In particular, the very tricky mkExpectedActualMsg function
is gone.
It took me a full day. But the result is far easier to understand.
(Still not easy!) This led to various minor improvements in error
output, and an enormous number of test-case error wibbles.
One particular point: for occurs-check errors I now just say
Can't match 'a' against '[a]'
rather than using the intimidating language of "occurs check".
* Pretty-printing AbsBinds
Tests review
* Eta expansions
T11305: one eta expansion
T12082: one eta expansion (undefined)
T13585a: one eta expansion
T3102: one eta expansion
T3692: two eta expansions (tricky)
T2239: two eta expansions
T16473: one eta
determ004: two eta expansions (undefined)
annfail06: two eta (undefined)
T17923: four eta expansions (a strange program indeed!)
tcrun035: one eta expansion
* Ambiguity check at higher rank. Now that we have simple
subsumption, a type like
f :: (forall a. Eq a => Int) -> Int
is no longer ambiguous, because we could write
g :: (forall a. Eq a => Int) -> Int
g = f
and it'd typecheck just fine. But f's type is a bit
suspicious, and we might want to consider making the
ambiguity check do a check on each sub-term. Meanwhile,
these tests are accepted, whereas they were previously
rejected as ambiguous:
T7220a
T15438
T10503
T9222
* Some more interesting error message wibbles
T13381: Fine: one error (Int ~ Exp Int)
rather than two (Int ~ Exp Int, Exp Int ~ Int)
T9834: Small change in error (improvement)
T10619: Improved
T2414: Small change, due to order of unification, fine
T2534: A very simple case in which a change of unification order
means we get tow unsolved constraints instead of one
tc211: bizarre impredicative tests; just accept this for now
Updates Cabal and haddock submodules.
Metric Increase:
T12150
T12234
T5837
haddock.base
Metric Decrease:
haddock.compiler
haddock.Cabal
haddock.base
Merge note: This appears to break the
`UnliftedNewtypesDifficultUnification` test. It has been marked as
broken in the interest of merging.
(cherry picked from commit 66b7b195cb3dce93ed5078b80bf568efae904cc5)
|
| |
|
|
|
|
|
|
| |
As noted in !3132, this has rather severe knock-on consequences in
user-code. We'll need to revisit this before merging something along
these lines.
This reverts commit 9749fe1223d182b1f8e7e4f7378df661c509f396.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, holes (both expression holes / out of scope variables and
partial-type-signature wildcards) were emitted as *constraints* via
the CHoleCan constructor. While this worked fine for error reporting,
there was a fair amount of faff in keeping these constraints in line.
In particular, and unlike other constraints, we could never change
a CHoleCan to become CNonCanonical. In addition:
* the "predicate" of a CHoleCan constraint was really the type
of the hole, which is not a predicate at all
* type-level holes (partial type signature wildcards) carried
evidence, which was never used
* tcNormalise (used in the pattern-match checker) had to create
a hole constraint just to extract it again; it was quite messy
The new approach is to record holes directly in WantedConstraints.
It flows much more nicely now.
Along the way, I did some cleaning up of commentary in
GHC.Tc.Errors.Hole, which I had a hard time understanding.
This was instigated by a future patch that will refactor
the way predicates are handled. The fact that CHoleCan's
"predicate" wasn't really a predicate is incompatible with
that future patch.
No test case, because this is meant to be purely internal.
It turns out that this change improves the performance of
the pattern-match checker, likely because fewer constraints
are sloshing about in tcNormalise. I have not investigated
deeply, but an improvement is not a surprise here:
-------------------------
Metric Decrease:
PmSeriesG
-------------------------
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
I omitted a vital zonk when refactoring tcHsPartialType in
commit 48fb3482f8cbc8a4b37161021e846105f980eed4
Author: Simon Peyton Jones <simonpj@microsoft.com>
Date: Wed Jun 5 08:55:17 2019 +0100
Fix typechecking of partial type signatures
This patch fixes it and adds commentary to explain why.
Fixes #18008
|
| |
|
|
|
| |
This fixes several small oversights in the choice of pretty-printing
function to use. Fixes #18052.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, if we had a [W] (a :: k1) ~ (rhs :: k2), we would
spit out a [D] k1 ~ k2 and part the W as irreducible, hoping for
a unification. But we needn't do this. Instead, we now spit out
a [W] co :: k2 ~ k1 and then use co to cast the rhs of the original
Wanted. This means that we retain the connection between the
spat-out constraint and the original.
The problem with this new approach is that we cannot use the
casted equality for substitution; it's too like wanteds-rewriting-
wanteds. So, we forbid CTyEqCans that mention coercion holes.
All the details are in Note [Equalities with incompatible kinds]
in TcCanonical.
There are a few knock-on effects, documented where they occur.
While debugging an error in this patch, Simon and I ran into
infelicities in how patterns and matches are printed; we made
small improvements.
This patch includes mitigations for #17828, which causes spurious
pattern-match warnings. When #17828 is fixed, these lines should
be removed.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
We now always show "forall {a}. T" for inferred variables,
previously this was controlled by -fprint-explicit-foralls.
This implements part 1 of https://github.com/ghc-proposals/ghc-proposals/pull/179.
Part of GHC ticket #16320.
Furthermore, when printing a levity restriction error, we now display
the HsWrap of the expression. This lets users see the full elaboration with
-fprint-typechecker-elaboration (see also #17670)
|
| |
|
|
|
|
|
|
|
| |
This patch avoids skolemiseUnboundMetaTyVar making
up a fresh Name when it doesn't need to.
See Note [Skolemising and identity]
Improves error messsages for partial type signatures.
|
| |
|
|
|
|
|
|
|
| |
This changes GHC's treatment of so-called Naughty Quantification
Candidates to issue errors, instead of zapping to Any.
Close #16775.
No new test cases, because existing ones cover this well.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before this patch, GHC always printed the * kind unparenthesized.
This led to two issues:
1. Sometimes GHC printed invalid or incorrect code.
For example, GHC would print: type F @* x = x
when it meant to print: type F @(*) x = x
In the former case, instead of a kind application we were getting a
type operator (@*).
2. Sometimes GHC printed kinds that were correct but hard to read.
Should Either * Int be read as Either (*) Int
or as (*) Either Int ?
This depends on whether -XStarIsType is enabled, but it would be
easier if we didn't have to check for the flag when reading the code.
We can solve both problems by assigning (*) a different precedence. Note
that Haskell98 kinds are not affected:
((* -> *) -> *) -> * does NOT become (((*) -> (*)) -> (*)) -> (*)
The parentheses are added when (*) is used in a function argument
position:
F * * * becomes F (*) (*) (*)
F A * B becomes F A (*) B
Proxy * becomes Proxy (*)
a * -> * becomes a (*) -> *
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch implements a part of GHC Proposal #229 that covers five
operators:
* the bang operator (!)
* the tilde operator (~)
* the at operator (@)
* the dollar operator ($)
* the double dollar operator ($$)
Based on surrounding whitespace, these operators are disambiguated into
bang patterns, lazy patterns, strictness annotations, type
applications, splices, and typed splices.
This patch doesn't cover the (-) operator or the -Woperator-whitespace
warning, which are left as future work.
|
| | |
|
| |
|
|
| |
This makes error messages a tad less noisy.
|
| | |
|
| |
|
|
|
|
|
|
| |
This fixes #15809, and is covered in
Note [Use level numbers for quantification] in TcMType.
This patch removes the "global tyvars" from the
environment, a nice little win.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit should have no change in behavior.(*)
The observation was that Note [Recipe for checking a signature]
says that every metavariable in a type-checked type must either
(A) be generalized
(B) be promoted
(C) be zapped.
Yet the code paths for doing these were all somewhat separate.
This led to some steps being skipped. This commit shores this
all up. The key innovation is TcHsType.kindGeneralizeSome, with
appropriate commentary.
This commit also sets the stage for #15809, by turning the
WARNing about bad level-numbers in generalisation into an
ASSERTion. The actual fix for #15809 will be in a separate
commit.
Other changes:
* zonkPromoteType is now replaced by kindGeneralizeNone.
This might have a small performance degradation, because
zonkPromoteType zonked and promoted all at once. The new
code path promotes first, and then zonks.
* A call to kindGeneralizeNone was added in tcHsPartialSigType.
I think this was a lurking bug, because it did not follow
Note [Recipe for checking a signature]. I did not try to
come up with an example showing the bug. This is the (*)
above.
Because of this change, there is an error message regression
in partial-sigs/should_fail/T14040a. This problem isn't really
a direct result of this refactoring, but is a symptom of
something deeper. See #16775, which addresses the deeper
problem.
* I added a short-cut to quantifyTyVars, in case there's
nothing to quantify.
* There was a horribly-outdated Note that wasn't referred
to. Gone now.
* While poking around with T14040a, I discovered a small
mistake in the Coercion.simplifyArgsWorker. Easy to fix,
happily.
* See new Note [Free vars in coercion hole] in TcMType.
Previously, we were doing the wrong thing when looking
at a coercion hole in the gather-candidates algorithm.
Fixed now, with lengthy explanation.
Metric Decrease:
T14683
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Partial type sigs had grown hair. tcHsParialSigType was
doing lots of unnecessary work, and tcInstSig was cloning it
unnecessarily -- and the result didn't even work: #16728.
This patch cleans it all up, described by TcHsType
Note [Checking parital type signatures]
I basically just deleted code... but very carefully!
Some refactoring along the way
* Distinguish more explicintly between "anonymous" wildcards "_"
and "named" wildcards "_a". I changed the names of a number
of functions to make this distinction much more apparent.
The patch also revealed that the code in `TcExpr`
that implements the special typing rule for `($)` was wrong.
It called `getRuntimeRep` in a situation where where was no
particular reason to suppose that the thing had kind `TYPE r`.
This caused a crash in typecheck/should_run/T10846.
The fix was easy, and actually simplifies the code in `TcExpr`
quite a bit. Hooray.
|
| | |
|
