Skip to content
Snippets Groups Projects
Commit b9605396 authored by Simon Peyton Jones's avatar Simon Peyton Jones Committed by Ryan Scott
Browse files

Fix scoping of TyCon binders in TcTyClsDecls

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.
parent fa37940c
No related branches found
No related tags found
Loading
Showing
with 626 additions and 299 deletions
Loading
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment