| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
This patch clarifies a dark corner of quantified
constraints.
* See Note [Yukky eq_sel for a HoleDest] in TcSMonad
* Minor refactor, breaking out new function
TcInteract.doTopReactEqPred
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch implements overloaded quotation brackets which generalise the
desugaring of all quotation forms in terms of a new minimal interface.
The main change is that a quotation, for example, [e| 5 |], will now
have type `Quote m => m Exp` rather than `Q Exp`. The `Quote` typeclass
contains a single method for generating new names which is used when
desugaring binding structures.
The return type of functions from the `Lift` type class, `lift` and `liftTyped` have
been restricted to `forall m . Quote m => m Exp` rather than returning a
result in a Q monad.
More details about the feature can be read in the GHC proposal.
https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0246-overloaded-bracket.rst
|
| |
|
|
|
|
|
|
|
|
|
| |
This brings the pretty-printer for Core in line with how visible
type applications are normally printed: namely, with no whitespace
after the `@` character (i.e., `f @a` instead of `f @ a`). While I'm
in town, I also give the same treatment to type abstractions (i.e.,
`\(@a)` instead of `\(@ a)`) and coercion applications (i.e.,
`f @~x` instead of `f @~ x`).
Fixes #17643.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Add 'dumpAction' hook to DynFlags.
It allows GHC API users to catch dumped intermediate codes and
information. The format of the dump (Core, Stg, raw text, etc.) is now
reported allowing easier automatic handling.
* Add 'traceAction' hook to DynFlags.
Some dumps go through the trace mechanism (for instance unfoldings that
have been considered for inlining). This is problematic because:
1) dumps aren't written into files even with -ddump-to-file on
2) dumps are written on stdout even with GHC API
3) in this specific case, dumping depends on unsafe globally stored
DynFlags which is bad for GHC API users
We introduce 'traceAction' hook which allows GHC API to catch those
traces and to avoid using globally stored DynFlags.
* Avoid dumping empty logs via dumpAction/traceAction (but still write
empty files to keep the existing behavior)
|
| |
|
|
|
|
| |
Close #17583.
Test case: typecheck/should_fail/T17563
|
| |
|
|
|
|
|
|
|
|
|
| |
As described in #17291, we'd like to separate coercions and expressions
in a more robust fashion.
This is a small step in this direction.
- `mkLocalId` now panicks on a covar.
Calls where this was not the case were changed to `mkLocalIdOrCoVar`.
- Don't use "OrCoVar" functions in places where we know the type is
not a coercion.
|
| |
|
|
| |
As suggested in #17291
|
| |
|
|
|
|
|
|
|
|
|
| |
Silly users sometimes try to use visible dependent quantification
and polymorphic recursion without a CUSK or SAK. This causes
unexpected errors. So we now adjust expectations with a bit
of helpful messaging.
Closes #17541 and closes #17131.
test cases: dependent/should_fail/T{17541{,b},17131}
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
We deliberately avoid defining a magical `Unit%` class, for reasons
that I have expounded upon in the newly added
`Note [Ignore unary constraint tuples]` in `TcHsType`. However, a
sneaky user could try to insert `Unit%` into their program by way of
Template Haskell, leading to the interface-file error observed
in #17511. To avoid this, any time we encounter a unary constraint
tuple during typechecking, we drop the surrounding constraint tuple
application. This is safe to do since `Unit% a` and `a` would be
semantically equivalent (unlike other forms of unary tuples).
Fixes #17511.
|
| | |
|
| |
|
|
|
| |
Since the invariants always hold in the testsuite, we can convert
them to asserts.
|
| |
|
|
|
| |
Metric Decrease:
haddock.compiler
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a refactoring with no user-visible changes (except for GHC API
users). Consider the HsExpr constructors that correspond to user-written
pragmas:
HsSCC representing {-# SCC ... #-}
HsCoreAnn representing {-# CORE ... #-}
HsTickPragma representing {-# GENERATED ... #-}
We can factor them out into a separate datatype, HsPragE. It makes the
code a bit tidier, especially in the parser.
Before this patch:
hpc_annot :: { Located ( (([AddAnn],SourceText),(StringLiteral,(Int,Int),(Int,Int))),
((SourceText,SourceText),(SourceText,SourceText))
) }
After this patch:
prag_hpc :: { Located ([AddAnn], HsPragE GhcPs) }
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In #17270 we have the pattern-match checker emit incorrect warnings. The
reason for that behavior is ultimately an inconsistency in whether we
treat TH splices as written by the user (`FromSource :: Origin`) or as
generated code (`Generated`). This was first reported in #14838.
The current solution is to TH splices as `Generated` by default and only
treat them as `FromSource` when the user requests so
(-fenable-th-splice-warnings). There are multiple reasons for opt-in
rather than opt-out:
* It's not clear that the user that compiles a splice is the author of the code
that produces the warning. Think of the situation where she just splices in
code from a third-party library that produces incomplete pattern matches.
In this scenario, the user isn't even able to fix that warning.
* Gathering information for producing the warnings (pattern-match check
warnings in particular) is costly. There's no point in doing so if the user
is not interested in those warnings.
Fixes #17270, but not #14838, because the proper solution needs a GHC
proposal extending the TH AST syntax.
|
| | |
|
| |
|
|
| |
This makes error messages a tad less noisy.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
`GHC.Prim.seq` previously had the rather plain type:
seq :: forall a b. a -> b -> b
However, it also had a special typing rule to applications
where `b` is not of kind `Type`.
Issue #17440 noted that levity polymorphism allows us to rather give
it the more precise type:
seq :: forall (r :: RuntimeRep) a (b :: TYPE r). a -> b -> b
This allows us to remove the special typing rule that we previously
required to allow applications on unlifted arguments. T9404 contains a
non-Type application of `seq` which should verify that this works as
expected.
Closes #17440.
|
| |
|
|
|
| |
Metric Decrease:
T14683
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously an import cycle between Type and TyCoRep meant that several
functions in TyCoRep ended up SOURCE import coreView. This is quite
unfortunate as coreView is intended to be fused into a larger pattern
match and not incur an extra call.
Fix this with a bit of restructuring:
* Move the functions in `TyCoRep` which depend upon things in `Type`
into `Type`
* Fold contents of `Kind` into `Type` and turn `Kind` into a simple
wrapper re-exporting kind-ish things from `Type`
* Clean up the redundant imports that popped up as a result
Closes #17441.
Metric Decrease:
T4334
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, we checked all imported type family equations
for injectivity. This is very silly. Now, we check only
for conflicts.
Before I could even imagine doing the fix, I needed to untangle
several functions that were (in my opinion) overly complicated.
It's still not quite as perfect as I'd like, but it's good enough
for now.
Test case: typecheck/should_compile/T17405
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We can handle non-void constraints since !1733, so we can now express
the strictness of `-XEmptyCase` just by adding a non-void constraint
to the initial Uncovered set.
For `case x of {}` we thus check that the Uncovered set `{ x | x /~ ⊥ }`
is non-empty. This is conceptually simpler than the plan outlined in
#17376, because it talks to the oracle directly.
In order for this patch to pass the testsuite, I had to fix handling of
newtypes in the pattern-match checker (#17248).
Since we use a different code path (well, the main code path) for
`-XEmptyCase` now, we apparently also handle #13717 correctly.
There's also some dead code that we can get rid off now.
`provideEvidence` has been updated to provide output more in line with
the old logic, which used `inhabitationCandidates` under the hood.
A consequence of the shift away from the `UncoveredPatterns` type is
that we don't report reduced type families for empty case matches,
because the pretty printer is pure and only knows the match variable's
type.
Fixes #13717, #17248, #17386
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since the Trees That Grow effort started, we had `type LPat = Pat`.
This is so that `SrcLoc`s would only be annotated in GHC's AST, which is
the reason why all GHC passes use the extension constructor `XPat` to
attach source locations. See #15495 for the design discussion behind
that.
But now suddenly there are `XPat`s everywhere!
There are several functions which dont't cope with `XPat`s by either
crashing (`hsPatType`) or simply returning incorrect results
(`collectEvVarsPat`).
This issue was raised in #17330. I also came up with a rather clean and
type-safe solution to the problem: We define
```haskell
type family XRec p (f :: * -> *) = r | r -> p f
type instance XRec (GhcPass p) f = Located (f (GhcPass p))
type instance XRec TH f = f p
type LPat p = XRec p Pat
```
This is a rather modular embedding of the old "ping-pong" style, while
we only pay for the `Located` wrapper within GHC. No ping-ponging in
a potential Template Haskell AST, for example. Yet, we miss no case
where we should've handled a `SrcLoc`: `hsPatType` and
`collectEvVarsPat` are not callable at an `LPat`.
Also, this gets rid of one indirection in `Located` variants:
Previously, we'd have to go through `XPat` and `Located` to get from
`LPat` to the wrapped `Pat`. Now it's just `Located` again.
Thus we fix #17330.
|
| |
|
|
|
|
|
|
| |
GHC Proposal #229 changes the lexical rules of Haskell, which may
require slight whitespace adjustments in certain cases.
This patch changes formatting in a few places in GHC and its testsuite
in a way that enables it to compile under the proposed rules.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
with equality constraints
In #17304, Richard and Simon dicovered that using `-XFlexibleInstances`
for `Outputable` instances of AST data types means users can provide orphan
`Outputable` instances for passes other than `GhcPass`.
Type inference doesn't currently to suffer, and Richard gave an example
in #17304 that shows how rare a case would be where the slightly worse
type inference would matter.
So I went ahead with the refactoring, attempting to fix #17304.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Due to the way `DerivEnv` is currently structured, there is an
invariant that every derived instance must consist of a class applied
to a non-empty list of argument types, where the last argument *must*
be an application of a type constructor to some arguments. This works
for many cases, but there are also some design patterns in standalone
`anyclass`/`via` deriving that are made impossible due to enforcing
this invariant, as documented in #13154.
This fixes #13154 by refactoring `TcDeriv` and friends to perform
fewer validity checks when using the `anyclass` or `via` strategies.
The highlights are as followed:
* Five fields of `DerivEnv` have been factored out into a new
`DerivInstTys` data type. These fields only make sense for
instances that satisfy the invariant mentioned above, so
`DerivInstTys` is now only used in `stock` and `newtype` deriving,
but not in other deriving strategies.
* There is now a `Note [DerivEnv and DerivSpecMechanism]` describing
the bullet point above in more detail, as well as explaining the
exact requirements that each deriving strategy imposes.
* I've refactored `mkEqnHelp`'s call graph to be slightly less
complicated. Instead of the previous `mkDataTypeEqn`/`mkNewTypeEqn`
dichotomy, there is now a single entrypoint `mk_eqn`.
* Various bits of code were tweaked so as not to use fields that are
specific to `DerivInstTys` so that they may be used by all deriving
strategies, since not all deriving strategies use `DerivInstTys`.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Applicative-do has a bug where it fails to use the monadic fail method
when desugaring patternmatches which can fail. See #15344.
This patch fixes that problem. It required more rewiring than I had expected.
Applicative-do happens mostly in the renamer; that's where decisions about
scheduling are made. This schedule is then carried through the typechecker and
into the desugarer which performs the actual translation. Fixing this bug
required sending information about the fail method from the renamer, through
the type checker and into the desugarer. Previously, the desugarer didn't
have enough information to actually desugar pattern matches correctly.
As a side effect, we also fix #16628, where GHC wouldn't catch missing
MonadFail instances with -XApplicativeDo.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
19 times out of 20 we already have dynflags in scope.
We could just always use `return dflags`. But this is in fact not free.
When looking at some STG code I noticed that we always allocate a
closure for this expression in the heap. Clearly a waste in these cases.
For the other cases we can either just modify the callsite to
get dynflags or use the _D variants of withTiming I added which
will use getDynFlags under the hood.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
`TcSplice` was not properly handling oversaturated data family
instances, such as the example in #17296, as it dropped arguments due
to carelessly zipping data family instance arguments with
`tyConTyVars`. For data families, the number of `tyConTyVars` can
sometimes be less than the number of arguments it can accept in a
data family instance due to the fact that data family instances can
be oversaturated.
To account for this, `TcSplice.mkIsPolyTvs` has now been renamed to
`tyConArgsPolyKinded` and now factors in `tyConResKind` in addition
to `tyConTyVars`. I've also added
`Note [Reified instances and explicit kind signatures]` which
explains the various subtleties in play here.
Fixes #17296.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes #16512.
There are lots of parts of this patch:
* The main payload is in FamInst. See
Note [Coverage condition for injective type families] there
for the overview. But it doesn't fix the bug.
* We now bump the reduction depth every time we discharge
a CFunEqCan. See Note [Flatten when discharging CFunEqCan]
in TcInteract.
* Exploration of this revealed a new, easy to maintain invariant
for CTyEqCans. See Note [Almost function-free] in TcRnTypes.
* We also realized that type inference for injectivity was a
bit incomplete. This means we exchanged lookupFlattenTyVar for
rewriteTyVar. See Note [rewriteTyVar] in TcFlatten. The new
function is monadic while the previous one was pure, necessitating
some faff in TcInteract. Nothing too bad.
* zonkCt did not maintain invariants on CTyEqCan. It's not worth
the bother doing so, so we just transmute CTyEqCans to
CNonCanonicals.
* The pure unifier was finding the fixpoint of the returned
substitution, even when doing one-way matching (in tcUnifyTysWithTFs).
Fixed now.
Test cases: typecheck/should_fail/T16512{a,b}
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This introduces three new modules:
- basicTypes/Predicate.hs describes predicates, moving
this logic out of Type. Predicates don't really exist
in Core, and so don't belong in Type.
- typecheck/TcOrigin.hs describes the origin of constraints
and types. It was easy to remove from other modules and
can often be imported instead of other, scarier modules.
- typecheck/Constraint.hs describes constraints as used in
the solver. It is taken from TcRnTypes.
No work other than module splitting is in this patch.
This is the first step toward homogeneous equality, which will
rely more strongly on predicates. And homogeneous equality is the
next step toward a dependently typed core language.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
In #17343 we saw that we didn't handle the pattern guard `!_ <-
undefined` correctly: The `undefined` was never evaluated. Indeed,
elaboration failed to insert the invisible type aruments to `undefined`.
So `undefined` was trivially a normal-form and in turn never entered.
The problem is that we used to infer a sigma-type for the RHS of the
guard, the leading qualifiers of which will never be useful in a pattern
match situation. Hence we infer a rho-type now.
Fixes #17343.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Issue #17355 occurred because the control flow for
`TcValidity.check_valid_inst_head` was structured in such a way that
whenever it checked a special, built-in class (like `Generic` or
`HasField`), it would skip the most important check of all:
`checkValidTypePats`, which rejects nonsense like this:
```hs
instance Generic (forall a. a)
```
This fixes the issue by carving out `checkValidTypePats` from
`check_valid_inst_head` so that `checkValidTypePats` is always
invoked. `check_valid_inst_head` has also been renamed to
`check_special_inst_head` to reflect its new purpose of _only_
checking for instances headed by special classes.
Fixes #17355.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The latest installment in my quest to clean up the code in
`TcDeriv*`. This time, my sights are set on
`TcDerivInfer.inferConstraints`, which infers the context for derived
instances. This function is a wee bit awkward at the moment:
* It's not terribly obvious from a quick glance, but
`inferConstraints` is only ever invoked when using the `stock` or
`anyclass` deriving strategies, as the code for inferring the
context for `newtype`- or `via`-derived instances is located
separately in `mk_coerce_based_eqn`. But there's no good reason
for things to be this way, so I moved this code from
`mk_coerce_based_eqn` to `inferConstraints` so that everything
related to inferring instance contexts is located in one place.
* In this process, I discovered that the Haddocks for the auxiliary
function `inferConstraintsDataConArgs` are completely wrong. It
claims that it handles both `stock` and `newtype` deriving, but
this is completely wrong, as discussed above—it only handles
`stock`. To rectify this, I renamed this function to
`inferConstraintsStock` to reflect its actual purpose and created
a new `inferConstraintsCoerceBased` function to specifically
handle `newtype` (and `via`) deriving.
Doing this revealed some opportunities for further simplification:
* Removing the context-inference–related code from
`mk_coerce_based_eqn` made me realize that the overall structure
of the function is basically identical to `mk_originative_eqn`.
In fact, I was easily able to combine the two functions into a
single `mk_eqn_from_mechanism` function.
As part of this merger, I now invoke
`atf_coerce_based_error_checks` from `doDerivInstErrorChecks1`.
* I discovered that GHC defined this function:
```hs
typeToTypeKind = liftedTypeKind `mkVisFunTy` liftedTypeKind
```
No fewer than four times in different modules. I consolidated all
of these definitions in a single location in `TysWiredIn`.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
GHC has a wonderful-but-delicate mechanism for building recursive
dictionaries by adding a goal to the "solved dictionaries" before
solving the sub-goals. See Note [Solved dictionaries] in TcSMonad
Ticket #17267 showed that if you use this mechanism for local
/quantified/ constraints you can get a loop -- or even unsafe
coerce. This patch fixes the bug.
Specifically
* Make TcSMonad.addSolvedDict be conditional on using a
/top level/ instance, not a quantified one.
* Moreover, we /also/ don't want to add a solved dict
for equalities (a~b).
* Add lots more comments to Note [Solved dictionaries]
to explain the above cryptic stuff.
* Extend InstanceWhat to identify those strange built-in
equality instances.
A couple of other things along the way
* Delete the unused Type.isIPPred_maybe.
* Stop making addSolvedDict conditional on not being an
impolicit parameter. This comes from way back. But
it's irrelevant now because IP dicts are never solved
via an instance.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
GHC is suposed to uphold the principle that an /inferred/ type
for a let-binding should obey the rules for that module. E.g.
we should only accept an inferred higher rank type if we have
RankNTypes on.
But we were failing to check this: TcValidity.checkValidType
allowed arbitrary rank for inferred types.
This patch fixes the bug. It might in principle cause some breakage,
but if so that's good: the user should add RankNTypes and/or a
manual signature. (And almost every package has explicit user
signatures for all top-level things anyway.) Let's see.
Fixes #17213.
Metric Decrease:
T10370
|
| |
|
|
|
|
|
|
|
|
|
| |
Issue #17339 was caused by using a slightly different version of
`newDFunName` for derived instances that, confusingly enough, did not
take all arguments to the class into account when generating the
`DFun` name. I cannot think of any good reason for doing this, so
this patch uses `newDFunName` uniformly for both derived instances
and manually written instances alike.
Fixes #17339.
|
