#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