[GHC] #11245: Non-exhaustive pattern, "Patterns not matched" list is empty

[GHC]

#11245: Non-exhaustive pattern, "Patterns not matched" list is empty
-------------------------------------+-------------------------------------
        Reporter:  osa1              |                Owner:  gkaracha
            Type:  bug               |               Status:  new
        Priority:  normal            |            Milestone:
       Component:  Compiler          |              Version:  7.11
      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 gkaracha):

 Replying to [comment:5 osa1]:
 > I don't understand the argument about the definition not having any
 arguments. The exhaustiveness checker somehow checking for some patterns,
 right? And on the process it has to realize that some patterns are not
 checked. Whatever that it's finding on the process, it should print! Am I
 missing anything?

 Yes, this is true! But there are at least two good reasons at the moment
 for not printing this information:

  * This information may be too much for the eye (think of a big definition
 with a
    well-populated `where`-clause, like the ones you often find in GHC
 itself). Don't forget
    that the bag contains **all** constraints that are in scope,
 independently of being
    relevant to the specific match or not.

  * The pattern match checker does some simplifications in order to have
 reasonable performance
    and memory requirements. As you can see, there are already many
 problems concerning the
    checker's performance: #11195, #11239, #11276, ... so I would not push
 it more at the
    moment.

 The simplifications I am talking about are important not only for
 performance but also for the
 consistency of the final result and its usefulness to the user. At the
 moment the checker does
 not substitute in `HsExpr`. Instead, I have lifted `HsExpr` to `PmExpr`:
 {{{#!hs
 data PmExpr = PmExprVar   Id
              | PmExprCon   DataCon [PmExpr]
              | PmExprLit   PmLit
              | PmExprEq    PmExpr PmExpr  -- Syntactic equality
              | PmExprOther (HsExpr Id)    -- Note [PmExprOther in PmExpr]
 }}}

 Term substitution at the moment does not affect `PmExprOther` (see
 function `substPmExpr`
 in `deSugar/PmExpr.hs`) because substituting in `HsSyn` would be massive
 and at the moment
 would affect only the appearance but not the expressive power of the
 check. Hence, the final
 result may look inconsistent (it is not, because we do not actually
 inspect `HsExpr` at all
 so substituting or not at the moment makes no difference). I would like to
 give something
 more detailed to the user too but for the moment I think it is not a
 priority so, for now,
 I'd go with what I showed above, until I have a nice solution to these
 problems.

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