Be more careful when naming TyCon binders
This patch fixes two rather gnarly test cases:
- Trac Trac #16342 (mutual recursion) See Note [Tricky scoping in generaliseTcTyCon]
- Trac 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.