#15052: DeriveAnyClass instances may skip TypeError constraints -------------------------------------+------------------------------------- Reporter: jcpetruzza | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: | CustomTypeErrors 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): When `deriving` infers an instance context, it collects some set of constraints, simplifies them as much as possible (discharging constraints when possible), and uses the remaining constraints as the context. For instance, in `data T a = MkT a Int deriving Show`, you start with the constraint set `(Show a, Show Int)`. GHC is able to discharge the `Show Int` constraint, since there's a top-level instance for that, but not the `Show a` constraint, so the final instance context is `Show a`. Returning to your `TypeError` example, you start with a constraint set that contains many constraints, with `TypeError (...)` sprinkled among them. There is no way to discharge a `TypeError (...)` constraint—if you could, you would be able to do lots of things you weren't supposed to be able to do, since `TypeError` is designed to be the context for unreachable code! Thus, `TypeError (...)` ends up in the final instance context. At this point, you might be thinking "well why doesn't the constraint solver immediately error when it encounters any constraint mentioning `TypeError`"? That might be feasible, but again, it would be a breaking change—it would explicitly go against the convention established by #14339. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/15052#comment:10 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler