#14813: EmptyCase thinks pattern match involving type family is not exhaustive, when it actually is -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): OK I undersatand now. My question in comment:3 was after reading comment:2. But comment:1 makes it clear why we want to improve `inhabitationCandidates`. Essentially you want to normalise a type using both top-level instances ''and'' local equalities. The constraint solver does this all the time, so the Right Thing is probably just to expose a new API to the constraint solver, alongside `tcCheckSatisfiability`. Something like {{{ tcNormalise :: Bag EvVar -> Type -> TcM Type }}} How would it work? A bit like `tcCheckSatisfiability`, except that after the `solveGivens` call `solveWanteds` passing a single `CHoleCan` constraint. It is not "solved", but it ''is'' normalised. So the `solveWanteds` will return a `CHoleCan` whose type is the desired normalised one. For efficiency, you might want to do a quick check before invoking `tcNormalise`, in case the type is ''already'' an algebraic data type (a common case), in which case normalisation will be a no-op. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14813#comment:6 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler