[GHC] #13766: Confusing "redundant pattern match" in 8.0, no warning at all in 8.2

[GHC]

#13766: Confusing "redundant pattern match" in 8.0, no warning at all in 8.2
-------------------------------------+-------------------------------------
        Reporter:  edsko             |                Owner:  (none)
            Type:  bug               |               Status:  new
        Priority:  normal            |            Milestone:
       Component:  Compiler          |              Version:  8.0.1
      Resolution:                    |             Keywords:
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):

 I talked with mpickering about this privately, but I'll recap the
 conversation here as well.

 This may be expected behavior the sense of comment:5, but I still find it
 unsettling. The code that adb565aa74582969bbcc3b411d6d518b1c76c3cf
 targeted was of the form:

 {{{#!hs
 f = case [] of (_:_) -> case () of
                           a -> undefined
 }}}

 Here, it'll warn that the `(_:_)` match is redundant:

 {{{
     Pattern match is redundant
     In a case alternative: (_ : _) -> ...
 }}}

 And thanks to the aforementioned commit, it will //not// warn about the
 inaccessible `a -> undefined` case. This is definitely a Good Thing.

 A similar scenario arises in the code in this example:

 {{{#!hs
 instance Int ~ Bool => C Int where
   c = id
 }}}

 Because `Int ~ Bool` is insoluble (and thus all the code inside the
 instance is inaccessible), it won't bother printing out a warning that `c`
 is inaccessible. But this is a tad skeevy. In the former example, there
 was a separate warning that hinted that you were doing something
 questionable. In the latter example, however, there's no warning at all to
 point out the dubious nature of your code!

 Therefore, I think a satisfactory conclusion to this bug would be to come
 up with a suitable warning about the `Int ~ Bool` constraint. Whether
 that's the purview of #12694 or some other ticket, I'm not sure.

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13766#comment:6>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler