#12503: Template Haskell regression: GHC erroneously thinks a type variable is also a kind -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Template Haskell | Version: 8.0.1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I _think_ I know what's happening here. The kind equalities patch changed `FreeKiTyVars` from this: {{{#!hs type FreeKiTyVars = ([RdrName], [RdrName]) }}} to this: {{{#!hs data FreeKiTyVars = FKTV { fktv_kis :: [Located RdrName] , _fktv_k_set :: OccSet -- for efficiency, -- only used internally , fktv_tys :: [Located RdrName] , _fktv_t_set :: OccSet , fktv_all :: [Located RdrName] } }}} Now `FreeKiTyVars` is using two `OccSets`. (One each for the kind and type variables extracted so far? That's what I'm guessing, since `Note [Kind and type-variable binders]` is out of date.) The problem is that two exact `RdrName`s reified from Template Haskell can have the same underlying `Unique` but with different `Name`s (see `Note [Local bindings with Exact Names]`). That is what is shown in comment:7 — two exact `RdrName`s (`k`) have the same `Unique` (`vESeYM`), but different `Name`s (`a1lx` and `a1ly`). But as far as fixing this goes, I am a bit clueless. I suppose we could add `NameSet`s to `FreeKiTyVars` as well that track only `Exact` `RdrName`s, and if `lookupLocalRdrEnv` finds a hit for an `RdrName`, we could use the corresponding `NameSet`. Otherwise, fall back to the `OccSet`. Thoughts, Richard? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12503#comment:8 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler