| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This implements a first step towards #16762 by changing the renamer
to always use `rnImplicitBndrs` to bring implicitly bound type
variables into scope. The main change is in `rnFamInstEqn` and
`bindHsQTyVars`, which previously used _ad hoc_ methods of binding
their implicit tyvars.
There are a number of knock-on consequences:
* One of the reasons that `rnFamInstEqn` used an _ad hoc_ binding
mechanism was to give more precise source locations in
`-Wunused-type-patterns` warnings. (See
https://gitlab.haskell.org/ghc/ghc/issues/16762#note_273343 for an
example of this.) However, these warnings are actually a little
_too_ precise, since implicitly bound type variables don't have
exact binding sites like explicitly bound type variables do.
A similar problem existed for
"`Different names for the same type variable`" errors involving
implicit tyvars bound by `bindHsQTyVars`.
Therefore, we simply accept the less precise (but more accurate)
source locations from `rnImplicitBndrs` in `rnFamInstEqn` and
`bindHsQTyVars`. See
`Note [Source locations for implicitly bound type variables]` in
`GHC.Rename.HsType` for the full story.
* In order for `rnImplicitBndrs` to work in `rnFamInstEqn`, it needs
to be able to look up names from the parent class (in the event
that we are renaming an associated type family instance). As a
result, `rnImplicitBndrs` now takes an argument of type
`Maybe assoc`, which is `Just` in the event that a type family
instance is associated with a class.
* Previously, GHC kept track of three type synonyms for free type
variables in the renamer: `FreeKiTyVars`, `FreeKiTyVarsDups`
(which are allowed to contain duplicates), and
`FreeKiTyVarsNoDups` (which contain no duplicates). However, making
is a distinction between `-Dups` and `-NoDups` is now pointless, as
all code that returns `FreeKiTyVars{,Dups,NoDups}` will eventually
end up being passed to `rnImplicitBndrs`, which removes duplicates.
As a result, I decided to just get rid of `FreeKiTyVarsDups` and
`FreeKiTyVarsNoDups`, leaving only `FreeKiTyVars`.
* The `bindLRdrNames` and `deleteBys` functions are now dead code, so
I took the liberty of removing them.
|
|
|
This patch fixes #17566 by refactoring the way we decide the final
identity of the tyvars in the TyCons of a possibly-recursive nest
of type and class decls, possibly with associated types.
It's all laid out in
Note [Swizzling the tyvars before generaliseTcTyCon]
Main changes:
* We have to generalise each decl (with its associated types)
all at once: TcTyClsDecls.generaliseTyClDecl
* The main new work is done in TcTyClsDecls.swizzleTcTyConBndrs
* The mysterious TcHsSyn.zonkRecTyVarBndrs dies altogether
Other smaller things:
* A little refactoring, moving bindTyClTyVars from tcTyClDecl1
to tcDataDefn, tcSynRhs, etc. Clearer, reduces the number of
parameters
* Reduce the amount of swizzling required.
Specifically, bindExplicitTKBndrs_Q_Tv doesn't need
to clone a new Name for the TyVarTv, and not
cloning means that in the vasly common case,
swizzleTyConBndrs is a no-op
In detail:
Rename newTyVarTyVar --> cloneTyVarTyVar
Add newTyVarTyTyVar that doesn't clone
Use the non-cloning newTyVarTyVar in
bindExplicitTKBndrs_Q_Tv
Rename newFlexiKindedTyVarTyVar
--> cloneFlexiKindedTyVarTyVar
* Define new utility function and use it
HsDecls.familyDeclName ::
FamilyDecl (GhcPass p) -> IdP (GhcPass p)
Updates haddock submodule.
|
