diff options
| author | Ryan Scott <ryan.gl.scott@gmail.com> | 2020-07-05 16:15:01 -0400 |
|---|---|---|
| committer | Marge Bot <ben+marge-bot@smart-cactus.org> | 2020-11-06 03:45:28 -0500 |
| commit | e07e383a3250cb27a9128ad8d5c68def5c3df336 (patch) | |
| tree | b580fd84319138a3508303356318ac9b78750009 /testsuite/tests/patsyn/should_fail/T15694.stderr | |
| parent | 2125b1d6bea0c620e3a089603dace6bb38020c81 (diff) | |
| download | haskell-e07e383a3250cb27a9128ad8d5c68def5c3df336.tar.gz | |
Replace HsImplicitBndrs with HsOuterTyVarBndrs
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>
Diffstat (limited to 'testsuite/tests/patsyn/should_fail/T15694.stderr')
| -rw-r--r-- | testsuite/tests/patsyn/should_fail/T15694.stderr | 3 |
1 files changed, 2 insertions, 1 deletions
diff --git a/testsuite/tests/patsyn/should_fail/T15694.stderr b/testsuite/tests/patsyn/should_fail/T15694.stderr index 7e1507c332..2b0b7b77b1 100644 --- a/testsuite/tests/patsyn/should_fail/T15694.stderr +++ b/testsuite/tests/patsyn/should_fail/T15694.stderr @@ -2,6 +2,7 @@ T15694.hs:22:35: error: • Expected kind ‘k1 -> k0’, but ‘f a1’ has kind ‘ks’ ‘ks’ is a rigid type variable bound by - the data constructor ‘ASSO’ + an explicit forall ks k (f :: k -> ks) (a1 :: k) (ctx :: Ctx ks) + (ks1 :: Type) k1 (a2 :: k1) (ctx1 :: Ctx ks1) a3 at T15694.hs:18:30-31 • In the first argument of ‘(~~)’, namely ‘f a1 a2’ |