[GHC] #13154: Standalone-derived anyclass instances aren't as permissive as empty instances

19 Jan 2017

      #13154: Standalone-derived anyclass instances aren't as permissive as empty
instances
-------------------------------------+-------------------------------------
           Reporter:  RyanGlScott    |             Owner:  RyanGlScott
               Type:  bug            |            Status:  new
           Priority:  normal         |         Milestone:
          Component:  Compiler       |           Version:  8.1
  (Type checker)                     |
           Keywords:                 |  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:
-------------------------------------+-------------------------------------
 Note that these are accepted:

 {{{#!hs
 class Foo (a :: TYPE ('TupleRep '[]))
 instance Foo (a :: TYPE ('TupleRep '[]))
 instance Foo (##)
 }}}

 But if you try to write these same instances using `DeriveAnyClass` and
 `StandaloneDeriving`, they'll be rejected for no good reason:

 {{{#!hs
 deriving instance Foo (a :: TYPE ('TupleRep '[]))

 {-
     • Can't make a derived instance of ‘Foo a’:
         The last argument of the instance must be a data or newtype
 application
 -}

 deriving instance Foo (##)

 {-
     • Can't make a derived instance of ‘Foo (# #)’:
         The last argument of the instance cannot be an unboxed tuple
 -}
 }}}

 The latter error is a vestige of #12512, and should be easy enough to
 rectify. The former error is a bit tricker to fix, since much of the code
 in `TcDeriv`/`TcDerivInfer` assumes that the type to which the class is
 applied to in the instead head is a datatype or newtype `TyCon`. It's
 apparent that this doesn't hold true in the presence of `DeriveAnyClass`,
 however, so that code should be refactored to reflect this.

 For practical reasons, however, it might be best to wait until after
 #12144 is fixed to tackle this one, since that splits out some logic in
 `TcDerivInfer` for `DeriveAnyClass` so as to make it no longer rely on the
 aforementioned `TyCon` invariant.

--
Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13154
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler