[GHC] #14813: EmptyCase thinks pattern match involving type family is not exhaustive, when it actually is
GHC
ghc-devs at haskell.org
Fri Aug 17 08:00:29 UTC 2018
#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
More information about the ghc-tickets
mailing list