GHC has a module in the desugarer (Check) which checks whether patterns are overlapping and/or exhaustive, to support the flags -fwarn-overlapping-patterns and -fwarn-non-exhaustive-patterns. The code is old and crufty, and has several outstanding bugs. A rewrite is needed.
Edited
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Child items
0
Show closed items
No child items are currently assigned. Use child items to break down this issue into smaller parts.
Linked items
0
Link issues together to show that they're related or that one is blocking others.
Learn more.
I won't work with this task, because I've not found the relevance. Issue #322 doens't seem to be fixable, and issue #2204 and #1307 are only about improving the error message.
No, no one is working on it, as far as I know, and I would love someone to pay attention to it. There are a bunch of related tickets: at least #595 (closed), #5728 (closed), #3927 (closed), #5724 (closed), #5762 (closed), #4139 (closed). It has the great merit of being a nicely-separable task, one that doesn't interact with the rest of GHC.
However these papers focus entirely on a "block" of pattern matching, for example, a function defined by pattern matching. Many of the tickets go further:
Consider
f xs@(y:ys) = .....case xs of { (y:ys) -> ... }
The inner pattern match should not complain about a missing nil case. You may think this is a silly program, but it's less silly when record updates are concerned.
Matches that involve GADTs. Here things are a bit more complicated, and involve figuring out what branches are inaccessible because of type constraints. It's not that hard, but generating good warnings goes beyond what the literature covers.
I don't want to supervise this, but would would be happy to offer advice and guidance about GHC aspects, if someone else would lead.