[GHC] #8128: Standalone deriving fails for GADTs due to inaccessible code

[GHC]

#8128: Standalone deriving fails for GADTs due to inaccessible code
----------------------------------------------+----------------------------
        Reporter:  adamgundry                 |            Owner:
            Type:  bug                        |           Status:  new
        Priority:  normal                     |        Milestone:
       Component:  Compiler (Type checker)    |          Version:  7.7
      Resolution:                             |         Keywords:
Operating System:  Unknown/Multiple           |     Architecture:
 Type of failure:  GHC rejects valid program  |  Unknown/Multiple
       Test Case:                             |       Difficulty:  Unknown
        Blocking:                             |       Blocked By:
                                              |  Related Tickets:
----------------------------------------------+----------------------------

Comment (by adamgundry):

 You're right that it is tricky to decide whether a constructor could match
 in general (see #3927 and friends). Thus the "inaccessible code" error is
 necessarily somewhat conservative. But the point of this ticket is to make
 the standalone deriving machinery line up with the inaccessibility test,
 not to make the inaccessibility test perfect. In your example, since the
 match on `B2` is not obviously inaccessible, then it should be included;
 indeed it works in GHC right now.

 I had hoped that this would just be a case of testing `dataConCannotMatch`
 in the standalone deriving code. But on further investigation, it seems
 that "inaccessible code" results when the constraint solver deduces an
 obviously bogus constraint (e.g. `Int ~ Bool`), which covers more cases
 than `dataConCannotMatch`.

 Another option presents itself: we could add a flag that means "silently
 ignore inaccessible code", and check derived instances with the flag set.
 After all, if a branch in a derived instance is inaccessible, we may as
 well just throw it away. Such a flag might be useful also in situations
 where one version of GHC deduces that a match is inaccessible, but another
 version requires its presence to satisfy the exhaustiveness checker.

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