[GHC] #11732: Deriving Generic1 interacts poorly with TypeInType

[GHC]

#11732: Deriving Generic1 interacts poorly with TypeInType
-------------------------------------+-------------------------------------
        Reporter:  goldfire          |                Owner:
            Type:  bug               |               Status:  new
        Priority:  normal            |            Milestone:
       Component:  Compiler          |              Version:  8.1
      Resolution:                    |             Keywords:  TypeInType,
                                     |  Generics
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  None/Unknown      |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by RyanGlScott):

 Replying to [comment:4 goldfire]:
 > But
 >
 > {{{
 > data Proxy k (a :: k) deriving Functor
 > }}}
 >
 > would try `instance Functor (Proxy k)`, which is ill-kinded. GHC is
 surely clever enough to figure out that it should really do `instance
 Functor (Proxy *)`, but I think it should refrain from doing this.

 Right, that's what I mean by "instantiation check". Currently, GHC
 [http://git.haskell.org/ghc.git/blob/685398ebc5c8377597714cd8c3e97439d32e3a02:/compiler/typecheck/TcDeriv.hs#l605
 unifies the kind of the typeclass] with the kind of the datatype. If, in
 this process, it ends up instantiating a visible `TyBinder` in the
 datatype with something other than a type variable, it should be rejected.

 > More to the point of this ticket: I have a bad feeling my fix for #11357
 is utterly broken, in that it uses the `tc_args` from the instance tycon
 despite using visibilities from the parent tycon. Of course, the `tc_args`
 don't match up. I suppose a `mkFamilyTyConApp` would work nicely here.
 >
 > But you seem to know much more about generics in GHC than I do. Do you
 think you could make this fix? I really do think we just need to use
 `mkFamilyTyConApp` in the right spot here.

 I'm not sure what help `mkFamilyTyConApp` would provide, to be honest. Are
 you saying to do something like this:

 {{{#!hs
 let (tc', tc_args') = splitTyConApp (mkFamilyTyConApp tc tc_args)
 }}}

 If so, wouldn't you'd end up with the data //family// tycon and arguments?
 I tried this, and while it seemed to fix the above issue, it comically
 broke something else:

 {{{#!hs
 data family URec p a
 data instance URec Char a = UChar
 }}}

 Since it mistakenly believes that `URec Char a` is too instantiated (it
 shouldn't even be considering `Char` at all, which is normally the case
 when you get your type arguments from
 [http://git.haskell.org/ghc.git/blob/685398ebc5c8377597714cd8c3e97439d32e3a02:/compiler/typecheck/TcDeriv.hs#l751
 tcLookupDataFamInst]).

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11732#comment:5>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler