
#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