| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
| |
The assertion that checked TyEq:N in canEqCanLHSFinish incorrectly
triggered in the case of an unsaturated newtype TyCon heading the RHS,
even though we can't unwrap such an application. Now, we only trigger
an assertion failure in case of a saturated application of a newtype
TyCon.
Fixes #22310
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When multiple Given quantified constraints match a Wanted, and there is
a quantified constraint that dominates all others, we now pick it
to solve the Wanted.
See Note [Use only the best matching quantified constraint].
For example:
[G] d1: forall a b. ( Eq a, Num b, C a b ) => D a b
[G] d2: forall a . C a Int => D a Int
[W] {w}: D a Int
When solving the Wanted, we find that both Givens match, but we pick
the second, because it has a weaker precondition, C a Int, compared
to (Eq a, Num Int, C a Int). We thus say that d2 dominates d1;
see Note [When does a quantified instance dominate another?].
This domination test is done purely in terms of superclass expansion,
in the function GHC.Tc.Solver.Interact.impliedBySCs. We don't attempt
to do a full round of constraint solving; this simple check suffices
for now.
Fixes #22216 and #22223
|
| |
|
|
|
|
|
|
|
| |
This fixes various typos and spelling mistakes
in the compiler.
Fixes #21891
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This MR adds diagnostic codes, assigning unique numeric codes to
error and warnings, e.g.
error: [GHC-53633]
Pattern match is redundant
This is achieved as follows:
- a type family GhcDiagnosticCode that gives the diagnostic code
for each diagnostic constructor,
- a type family ConRecursInto that specifies whether to recur into
an argument of the constructor to obtain a more fine-grained code
(e.g. different error codes for different 'deriving' errors),
- generics machinery to generate the value-level function assigning
each diagnostic its error code; see Note [Diagnostic codes using generics]
in GHC.Types.Error.Codes.
The upshot is that, to add a new diagnostic code, contributors only need
to modify the two type families mentioned above. All logic relating to
diagnostic codes is thus contained to the GHC.Types.Error.Codes module,
with no code duplication.
This MR also refactors error message datatypes a bit, ensuring we can
derive Generic for them, and cleans up the logic around constraint
solver reports by splitting up 'TcSolverReportInfo' into separate
datatypes (see #20772).
Fixes #21684
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch removes the TCvSubst data type and instead uses Subst as
the environment for both term and type level substitution. This
change is partially motivated by the existential type proposal,
which will introduce types that contain expressions and therefore
forces us to carry around an "IdSubstEnv" even when substituting for
types. It also reduces the amount of code because "Subst" and
"TCvSubst" share a lot of common operations. There isn't any
noticeable impact on performance (geo. mean for ghc/alloc is around
0.0% but we have -94 loc and one less data type to worry abount).
Currently, the "TCvSubst" data type for substitution on types is
identical to the "Subst" data type except the former doesn't store
"IdSubstEnv". Using "Subst" for type-level substitution means there
will be a redundant field stored in the data type. However, in cases
where the substitution starts from the expression, using "Subst" for
type-level substitution saves us from having to project "Subst" into a
"TCvSubst". This probably explains why the allocation is mostly even
despite the redundant field.
The patch deletes "TCvSubst" and moves "Subst" and its relevant
functions from "GHC.Core.Subst" into "GHC.Core.TyCo.Subst".
Substitution on expressions is still defined in "GHC.Core.Subst" so we
don't have to expose the definition of "Expr" in the hs-boot file that
"GHC.Core.TyCo.Subst" must import to refer to "IdSubstEnv" (whose
codomain is "CoreExpr"). Most functions named fooTCvSubst are renamed
into fooSubst with a few exceptions (e.g. "isEmptyTCvSubst" is a
distinct function from "isEmptySubst"; the former ignores the
emptiness of "IdSubstEnv"). These exceptions mainly exist for
performance reasons and will go away when "Expr" and "Type" are
mutually recursively defined (we won't be able to take those
shortcuts if we can't make the assumption that expressions don't
appear in types).
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There was an assert error, as Gergo pointed out in #21896.
I fixed this by adding an InScopeSet argument to tcUnifyTyWithTFs.
And also to GHC.Core.Unify.niFixTCvSubst.
I also took the opportunity to get a couple more InScopeSets right,
and to change some substTyUnchecked into substTy.
This MR touches a lot of other files, but only because I also took the
opportunity to introduce mkInScopeSetList, and use it.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The function breakTyVarCycle_maybe has been installed
in a dark corner of GHC to catch some gremlins (a.k.a.
occurs-check failures) who lurk
there. But it previously only caught gremlins of the
form (a ~ ... F a ...), where some of our intrepid users
have spawned gremlins of the form (G a ~ ... F (G a) ...).
This commit improves breakTyVarCycle_maybe (and renames
it to breakTyEqCycle_maybe) to catch the new gremlins.
Happily, the change is remarkably small.
The gory details are in Note [Type equality cycles].
Test cases: typecheck/should_compile/{T21515,T21473}.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We were considering all Typeable evidence to be "BuiltinInstance"s which
meant the stage restriction was going unchecked. In-fact, typeable has
evidence and so we need to apply the stage restriction.
This is
complicated by the fact we don't generate typeable evidence and the
corresponding DFunIds until after typechecking is concluded so we
introcue a new `InstanceWhat` constructor, BuiltinTypeableInstance which
records whether the evidence is going to be local or not.
Fixes #21547
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch fixes the unification of concrete type variables.
The subtlety was that unifying concrete metavariables is more subtle
than other metavariables, as decomposition is possible. See the Note
[Unifying concrete metavariables], which explains how we unify a
concrete type variable with a type 'ty' by concretising 'ty', using
the function 'GHC.Tc.Utils.Concrete.concretise'.
This can be used to perform an eager syntactic check for concreteness,
allowing us to remove the IsRefl# special predicate. Instead of emitting
two constraints `rr ~# concrete_tv` and `IsRefl# rr concrete_tv`, we
instead concretise 'rr'. If this succeeds we can fill 'concrete_tv',
and otherwise we directly emit an error message to the typechecker
environment instead of deferring. We still need the error message
to be passed on (instead of directly thrown), as we might benefit from
further unification in which case we will need to zonk the stored types.
To achieve this, we change the 'wc_holes' field of 'WantedConstraints'
to 'wc_errors', which stores general delayed errors. For the moement,
a delayed error is either a hole, or a syntactic equality error.
hasFixedRuntimeRep_MustBeRefl is now hasFixedRuntimeRep_syntactic, and
hasFixedRuntimeRep has been refactored to directly return the most
useful coercion for PHASE 2 of FixedRuntimeRep.
This patch also adds a field ir_frr to the InferResult datatype,
holding a value of type Maybe FRROrigin. When this value is not
Nothing, this means that we must fill the ir_ref field with a type
which has a fixed RuntimeRep.
When it comes time to fill such an ExpType, we ensure that the type
has a fixed RuntimeRep by performing a representation-polymorphism
check with the given FRROrigin
This is similar to what we already do to ensure we fill an Infer
ExpType with a type of the correct TcLevel.
This allows us to properly perform representation-polymorphism checks
on 'Infer' 'ExpTypes'.
The fillInferResult function had to be moved to GHC.Tc.Utils.Unify
to avoid a cyclic import now that it calls hasFixedRuntimeRep.
This patch also changes the code in matchExpectedFunTys to make use
of the coercions, which is now possible thanks to the previous change.
This implements PHASE 2 of FixedRuntimeRep in some situations.
For example, the test cases T13105 and T17536b are now both accepted.
Fixes #21239 and #21325
-------------------------
Metric Decrease:
T18223
T5631
-------------------------
|
|
|
|
| |
Close #21208.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As #20837 pointed out, `isLiftedType_maybe` returned `Just False` in
many situations where it should return `Nothing`, because it didn't
take into account type families or type variables.
In this patch, we fix this issue. We rename `isLiftedType_maybe` to
`typeLevity_maybe`, which now returns a `Levity` instead of a boolean.
We now return `Nothing` for types with kinds of the form
`TYPE (F a1 ... an)` for a type family `F`, as well as
`TYPE (BoxedRep l)` where `l` is a type variable.
This fix caused several other problems, as other parts of the compiler
were relying on `isLiftedType_maybe` returning a `Just` value, and were
now panicking after the above fix. There were two main situations in
which panics occurred:
1. Issues involving the let/app invariant. To uphold that invariant,
we need to know whether something is lifted or not. If we get an
answer of `Nothing` from `isLiftedType_maybe`, then we don't know
what to do. As this invariant isn't particularly invariant, we
can change the affected functions to not panic, e.g. by behaving
the same in the `Just False` case and in the `Nothing` case
(meaning: no observable change in behaviour compared to before).
2. Typechecking of data (/newtype) constructor patterns. Some programs
involving patterns with unknown representations were accepted, such
as T20363. Now that we are stricter, this caused further issues,
culminating in Core Lint errors. However, the behaviour was
incorrect the whole time; the incorrectness only being revealed by
this change, not triggered by it.
This patch fixes this by overhauling where the representation
polymorphism involving pattern matching are done. Instead of doing
it in `tcMatches`, we instead ensure that the `matchExpected`
functions such as `matchExpectedFunTys`, `matchActualFunTySigma`,
`matchActualFunTysRho` allow return argument pattern types which
have a fixed RuntimeRep (as defined in Note [Fixed RuntimeRep]).
This ensures that the pattern matching code only ever handles types
with a known runtime representation. One exception was that
patterns with an unknown representation type could sneak in via
`tcConPat`, which points to a missing representation-polymorphism
check, which this patch now adds.
This means that we now reject the program in #20363, at least until
we implement PHASE 2 of FixedRuntimeRep (allowing type families in
RuntimeRep positions). The aforementioned refactoring, in which
checks have been moved to `matchExpected` functions, is a first
step in implementing PHASE 2 for patterns.
Fixes #20837
|
|
|
|
| |
Close #20231.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch introduces a new kind of metavariable, by adding the
constructor `ConcreteTv` to `MetaInfo`. A metavariable with
`ConcreteTv` `MetaInfo`, henceforth a concrete metavariable, can only
be unified with a type that is concrete (that is, a type that answers
`True` to `GHC.Core.Type.isConcrete`).
This solves the problem of dangling metavariables in `Concrete#`
constraints: instead of emitting `Concrete# ty`, which contains a
secret existential metavariable, we simply emit a primitive equality
constraint `ty ~# concrete_tv` where `concrete_tv` is a fresh concrete
metavariable.
This means we can avoid all the complexity of canonicalising
`Concrete#` constraints, as we can just re-use the existing machinery
for `~#`.
To finish things up, this patch then removes the `Concrete#` special
predicate, and instead introduces the special predicate `IsRefl#`
which enforces that a coercion is reflexive.
Such a constraint is needed because the canonicaliser is quite happy
to rewrite an equality constraint such as `ty ~# concrete_tv`, but
such a rewriting is not handled by the rest of the compiler currently,
as we need to make use of the resulting coercion, as outlined in the
FixedRuntimeRep plan.
The big upside of this approach (on top of simplifying the code)
is that we can now selectively implement PHASE 2 of FixedRuntimeRep,
by changing individual calls of `hasFixedRuntimeRep_MustBeRefl` to
`hasFixedRuntimeRep` and making use of the obtained coercion.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
-------------------------
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The 'bad_newtype' assertion in GHC.Tc.Solver.Canonical.canEqCanLHSFinish
failed to account for the possibility that the newtype constructor
might not be in scope, in which case we don't provide any guarantees
about canonicalising away a newtype on the RHS of a representational
equality.
Fixes #21010
|
| |
|
|
|
|
| |
Fixes #21011
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
| |
Fix a simple omission in GHC.Tc.Solver.Canonical.solveForAll,
where we ended up with the wrong TcLclEnv captured in an implication.
Result: unhelpful error message (#21006)
|
|
|
|
|
|
|
|
|
| |
The second component is supposed to be "insoluble equalities arising
from givens". But we were getting wanteds too; and that led to an
outright duplication of constraints. It's not harmful, but it's not
right either.
I came across this when debugging something else. Easily fixed.
|
|
|
|
| |
This yields a small, but measurable, performance improvement.
|
|
|
|
|
|
|
|
|
|
| |
The `ctev_pred` field of a `CtEvidence` is a just a cache for the type
of the evidence. More precisely:
* For Givens, `ctev_pred` = `varType ctev_evar`
* For Wanteds, `ctev_pred` = `evDestType ctev_dest`
This new invariant is needed because evidence can become part of a
type, via `Castty ty kco`.
|
|
|
|
|
|
|
|
|
|
| |
See new Note [Use only the best local instance] in
GHC.Tc.Solver.Interact.
This commit also refactors the InstSC/OtherSC mechanism
slightly.
Close #20582.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, we reported things wrong with
f :: (Eq a, Ord a) => a -> Bool
f x = x == x
saying that Eq a was redundant. This is fixed now, along with
some simplification in Note [Replacement vs keeping]. There's
a tiny bit of extra complexity in setImplicationStatus, but
it's explained in Note [Tracking redundant constraints].
Close #20602
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
PHASE 1: we never rewrite Concrete# evidence.
This patch migrates all the representation polymorphism checks to
the typechecker, using a new constraint form
Concrete# :: forall k. k -> TupleRep '[]
Whenever a type `ty` must be representation-polymorphic
(e.g. it is the type of an argument to a function), we emit a new
`Concrete# ty` Wanted constraint. If this constraint goes
unsolved, we report a representation-polymorphism error to the user.
The 'FRROrigin' datatype keeps track of the context of the
representation-polymorphism check, for more informative error messages.
This paves the way for further improvements, such as
allowing type families in RuntimeReps and improving the soundness
of typed Template Haskell. This is left as future work (PHASE 2).
fixes #17907 #20277 #20330 #20423 #20426
updates haddock submodule
-------------------------
Metric Decrease:
T5642
-------------------------
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
By adding an early abort flag in `TcSEnv`, we can fail fast in the presence of
insoluble constraints. This helps us avoid a lot of work in valid hole-fits, and
we geta massive speed-up by avoiding a lot of useless work solving constraints that
never come into play.
Additionally, we add a simple check for degenerate hole types, such as
when the type of the hole is an immutable type variable (as is the case
when the hole is completely unconstrained). Then the only valid fits are
the locals, so we can ignore the global candidates.
This fixes #16875
|
|
|
|
|
|
|
|
|
|
|
|
| |
Close #20356.
See addendum to Note [coreView vs tcView] in GHC.Core.Type
for the details.
Also killed old Note about metaTyVarUpdateOK, which has been
gone for some time.
test case: typecheck/should_fail/T20356
|
|
|
|
|
|
|
|
|
|
|
| |
See Note [Equality on FunTys] in TyCoRep.
Close #17675.
Close #17655, about documentation improvements included in
this patch.
Close #19677, about a further mistake around FunTy.
test cases: typecheck/should_compile/T19677
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit adds the following constructors to the TcRnMessage type and
uses them to replace sdoc-based diagnostics in some parts of GHC (e.g.
TcRnUnknownMessage). It includes:
* Add TcRnMonomorphicBindings diagnostic
* Convert TcRnUnknownMessage in Tc.Solver.Interact
* Add and use the TcRnOrphanInstance constructor to TcRnMessage
* Add TcRnFunDepConflict and TcRnDupInstanceDecls constructors to TcRnMessage
* Add and use TcRnConflictingFamInstDecls constructor to TcRnMessage
* Get rid of TcRnUnknownMessage from GHC.Tc.Instance.Family
|
|
|
|
|
|
|
|
|
|
|
|
| |
This changes the TcPlugin datatype to allow type-checking plugins
to report insoluble constraints while at the same time solve
some other constraints. This allows better error messages, as
the plugin can still simplify constraints, even when it wishes
to report a contradiction.
Pattern synonyms TcPluginContradiction and TcPluginOk are provided
for backwards compatibility: existing type-checking plugins should
continue to work without modification.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We detect insoluble Givens by making getInertInsols
take into account TypeError constraints, on top of insoluble equalities
such as Int ~ Bool (which it already took into account).
This allows pattern matches with insoluble contexts to be reported
as redundant (tyOracle calls tcCheckGivens which calls getInertInsols).
As a bonus, we get to remove a workaround in Data.Typeable.Internal:
we can directly use a NotApplication type family, as opposed to
needing to cook up an insoluble equality constraint.
Fixes #11503 #14141 #16377 #20180
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Type-checking plugins can now directly rewrite type-families.
The TcPlugin record is given a new field, tcPluginRewrite.
The plugin specifies how to rewrite certain type-families with a value
of type `UniqFM TyCon TcPluginRewriter`, where:
type TcPluginRewriter
= RewriteEnv -- Rewriter environment
-> [Ct] -- Givens
-> [TcType] -- type family arguments
-> TcPluginM TcPluginRewriteResult
data TcPluginRewriteResult
= TcPluginNoRewrite
| TcPluginRewriteTo
{ tcPluginRewriteTo :: Reduction
, tcRewriterNewWanteds :: [Ct]
}
When rewriting an exactly-saturated type-family application,
GHC will first query type-checking plugins for possible rewritings
before proceeding.
Includes some changes to the TcPlugin API, e.g. removal
of the EvBindsVar parameter to the TcPluginM monad.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We define Reduction = Reduction Coercion !Type.
A reduction of the form 'Reduction co new_ty' witnesses an
equality ty ~co~> new_ty.
That is, the rewriting happens left-to-right: the right-hand-side
type of the coercion is the rewritten type, and the left-hand-side
type the original type.
Sticking to this convention makes the codebase more consistent,
helping to avoid certain applications of SymCo.
This replaces the parts of the codebase which represented reductions as
pairs, (Coercion,Type) or (Type,Coercion).
Reduction being strict in the Type argument improves performance
in some programs that rewrite many type families (such as T9872).
Fixes #20161
-------------------------
Metric Decrease:
T5321Fun
T9872a
T9872b
T9872c
T9872d
-------------------------
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As #19918 pointed out, the CallStack mechanism didn't work well with
RebindableSyntax.
This patch improves matters. See GHC.Tc.Types.Evidence
Note [Overview of implicit CallStacks]
* New predicate isPushCallStackOrigin distinguishes when a CallStack
constraint should be solved "directly" or by pushing an item on the
stack.
* The constructor EvCsPushCall now has a FastString, which can
describe not only a function call site, but also things like
"the literal 42" or "an if-then-else expression".
* I also fixed #20126 thus:
exprCtOrigin (HsIf {}) = IfThenElseOrigin
(Previously it was "can't happen".)
|
|
|
|
|
|
|
|
|
|
|
| |
This commit tries to untangle the zoo of diagnostic-related functions
in `Tc.Utils.Monad` so that we can have the interfaces mentions only
`TcRnMessage`s while we push the creation of these messages upstream.
It also ports TcRnMessage diagnostics to use the new API, in particular
this commit switch to use TcRnMessage in the external interfaces
of the diagnostic functions, and port the old SDoc to be wrapped
into TcRnUnknownMessage.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Introduce LogFlags as a independent subset of DynFlags used for logging.
As a consequence in many places we don't have to pass both Logger and
DynFlags anymore.
The main reason for this refactoring is that I want to refactor the
systools interfaces: for now many systools functions use DynFlags both
to use the Logger and to fetch their parameters (e.g. ldInputs for the
linker). I'm interested in refactoring the way they fetch their
parameters (i.e. use dedicated XxxOpts data types instead of DynFlags)
for #19877. But if I did this refactoring before refactoring the Logger,
we would have duplicate parameters (e.g. ldInputs from DynFlags and
linkerInputs from LinkerOpts). Hence this patch first.
Some flags don't really belong to LogFlags because they are subsystem
specific (e.g. most DumpFlags). For example -ddump-asm should better be
passed in NCGConfig somehow. This patch doesn't fix this tight coupling:
the dump flags are part of the UI but they are passed all the way down
for example to infer the file name for the dumps.
Because LogFlags are a subset of the DynFlags, we must update the former
when the latter changes (not so often). As a consequence we now use
accessors to read/write DynFlags in HscEnv instead of using `hsc_dflags`
directly.
In the process I've also made some subsystems less dependent on DynFlags:
- CmmToAsm: by passing some missing flags via NCGConfig (see new fields
in GHC.CmmToAsm.Config)
- Core.Opt.*:
- by passing -dinline-check value into UnfoldingOpts
- by fixing some Core passes interfaces (e.g. CallArity, FloatIn)
that took DynFlags argument for no good reason.
- as a side-effect GHC.Core.Opt.Pipeline.doCorePass is much less
convoluted.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit expands the old Note [Type variable cycles in Givens] to apply
as well to Deriveds. See the Note for details and examples. This fixes a
regression introduced by my earlier commit that killed off the flattener in
favor of the rewriter.
A few other things happened along the way:
* unifyTest was renamed to touchabilityTest, because that's what it does.
* isInsolubleOccursCheck was folded into checkTypeEq, which does much of the
same work. To get this to work out, though, we need to keep more careful
track of what errors we spot in checkTypeEq, and so CheckTyEqResult has
become rather more glorious.
* A redundant Note or two was eliminated.
* Kill off occCheckForErrors; due to Note [Rewriting synonyms], the
extra occCheckExpand here is always redundant.
* Store blocked equalities separately from other inerts; less stuff
to look through when kicking out.
Close #19682.
test case: typecheck/should_compile/T19682{,b}
|
|
|
|
|
|
|
|
|
|
|
| |
This creates new modules GHC.Tc.Solver.InertSet and
GHC.Tc.Solver.Types. The Monad module is still pretty
big, but this is an improvement. Moreover, it means
that GHC.HsToCore.Pmc.Solver.Types no longer depends
on the constraint solver (it now depends on GHC.Tc.Solver.InertSet),
making the error-messages work easier.
This patch thus contributes to #18516.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Replace uses of WARN macro with calls to:
warnPprTrace :: Bool -> SDoc -> a -> a
Remove the now unused HsVersions.h
Bump haddock submodule
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There is no reason to use CPP. __LINE__ and __FILE__ macros are now
better replaced with GHC's CallStack. As a bonus, assert error messages
now contain more information (function name, column).
Here is the mapping table (HasCallStack omitted):
* ASSERT: assert :: Bool -> a -> a
* MASSERT: massert :: Bool -> m ()
* ASSERTM: assertM :: m Bool -> m ()
* ASSERT2: assertPpr :: Bool -> SDoc -> a -> a
* MASSERT2: massertPpr :: Bool -> SDoc -> m ()
* ASSERTM2: assertPprM :: m Bool -> SDoc -> m ()
|
| |
|
|
|
|
|
| |
No changes to code; no changes to theory. Just better
explanation.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Close #17672.
By scratching our heads quite hard, we realized that
we should never kick out Given/Nominal equalities. This
commit tweaks the kick-out conditions accordingly.
See also Note [K4] which describes what is going on.
This does not fix a known misbehavior, but it should be
a small improvement in both practice (kicking out is bad,
and we now do less of it) and theory (a Given/Nominal should
behave just like a filled-in metavariable, which has no notion
of kicking out).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Kick out condition K2b really only makes sense for
inerts with a type variable on the left. This updates
the commentary and the code to skip this check for
inerts with type families on the left.
Also cleans up some commentary around solver invariants
and adds Note [K2b].
Close #19042.
test case: typecheck/should_compile/T19042
|
|
|
|
|
|
|
|
|
|
|
| |
Ticket #19415 showed a nasty typechecker loop, which can happen with
fundeps that do not satisfy the coverage condition.
This patch fixes the problem. It's described in GHC.Tc.Solver.Interact
Note [Fundeps with instances]
It's not a perfect solution, as the Note explains, but it's better
than the status quo.
|