Skip to content
  • Simon Peyton Jones's avatar
    Be more careful when naming TyCon binders · 80dfcee6
    Simon Peyton Jones authored and Marge Bot's avatar Marge Bot committed
    This patch fixes two rather gnarly test cases:
      * Trac #16342 (mutual recursion)
        See Note [Tricky scoping in generaliseTcTyCon]
    
      * Trac #16221 (shadowing)
        See Note [Unification variables need fresh Names]
    
    The main changes are:
    
    * Substantial reworking of TcTyClsDecls.generaliseTcTyCon
      This is the big change, and involves the rather tricky
      function TcHsSyn.zonkRecTyVarBndrs.
    
      See Note [Inferring kinds for type declarations] and
      Note [Tricky scoping in generaliseTcTyCon] for the details.
    
    * bindExplicitTKBndrs_Tv and bindImplicitTKBndrs_Tv both now
      allocate /freshly-named/ unification variables. Indeed, more
      generally, unification variables are always fresh; see
      Note [Unification variables need fresh Names] in TcMType
    
    * Clarify the role of tcTyConScopedTyVars.
      See Note [Scoped tyvars in a TcTyCon] in TyCon
    
    As usual, this dragged in some more refactoring:
    
    * Renamed TcMType.zonkTyCoVarBndr to zonkAndSkolemise
    
    * I renamed checkValidTelescope to checkTyConTelescope;
      it's only used on TyCons, and indeed takes a TyCon as argument.
    
    * I folded the slightly-mysterious reportFloatingKvs into
      checkTyConTelescope. (Previously all its calls immediately
      followed a call to checkTyConTelescope.)  It makes much more
      sense there.
    
    * I inlined some called-once functions to simplify
      checkValidTyFamEqn. It's less spaghetti-like now.
    
    * This patch also fixes Trac #16251.  I'm not quite sure why #16251
      went wrong in the first place, nor how this patch fixes it, but
      hey, it's good, and life is short.
    80dfcee6