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

[GHC]

#13154: Standalone-derived anyclass instances aren't as permissive as empty
instances
-------------------------------------+-------------------------------------
        Reporter:  RyanGlScott       |                Owner:  RyanGlScott
            Type:  bug               |               Status:  patch
        Priority:  normal            |            Milestone:  8.6.1
       Component:  Compiler (Type    |              Version:  8.1
  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:D4337
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by Ben Gamari <ben@…>):

 In [changeset:"1a911f217a18c8c0362ab2bf2b6ec7f7da015622/ghc"
 1a911f21/ghc]:
 {{{
 #!CommitTicketReference repository="ghc"
 revision="1a911f217a18c8c0362ab2bf2b6ec7f7da015622"
 Sequester deriving-related validity check into cond_stdOK

 Currently, any standalone-derived instance must satisfy the
 property that the tycon of the data type having an instance being
 derived for it must be either a normal ADT tycon or a data family
 tycon. But there are several other primitive tycons—such as `(->)`,
 `Int#`, and others—which cannot have standalone-derived instances
 (via the `anyclass` strategy) as a result of this check! See
 https://ghc.haskell.org/trac/ghc/ticket/13154#comment:8 for an
 example of where this overly conservative restriction bites.

 Really, this validity check only makes sense in the context of
 `stock` deriving, where we need the property that the tycon is that
 of a normal ADT or a data family in order to inspect its data
 constructors. Other deriving strategies don't require this validity
 check, so the most sensible way to fix this error is to move the
 logic of this check into `cond_stdOK`, which is specific to
 `stock` deriving.

 This makes progress towards fixing (but does not entirely fix)

 Test Plan: make test TEST=T13154a

 Reviewers: bgamari

 Reviewed By: bgamari

 Subscribers: rwbarton, thomie, carter

 GHC Trac Issues: #13154

 Differential Revision: https://phabricator.haskell.org/D4337
 }}}

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