#14579: GeneralizedNewtypeDeriving produces ambiguously-kinded code -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.2 checker) | Resolution: | Keywords: deriving Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4264 Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Ryan's visit to panictown notwithstanding, I'm still not convinced by comment:5. comment:5 seems to be suggesting that we need the generated code to pass through the renamer, so that the type variables can be captured. This is a reasonable guess. But `typeToLHsType`, as currently written (and working), uses `Exact` names, so the journey through the renamer doesn't capture anything. Perhaps the panic is actually caused by these lines in !RnTypes: {{{#!hs rnHsTyKi _ (HsCoreTy ty) = return (HsCoreTy ty, emptyFVs) -- The emptyFVs probably isn't quite right -- but I don't think it matters }}} Maybe it matters. Or maybe I'm missing something more fundamental. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14579#comment:7 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler