Opened 12 years ago

Closed 5 years ago

Last modified 19 months ago

#2204 closed feature request (duplicate)

Improve 'patterns not matched' warnings

Reported by: Deewiant Owned by:
Priority: low Milestone:
Component: Compiler Version: 6.8.2
Keywords: PatternMatchWarnings Cc: marcot@…
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: None/Unknown Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:

Description

Compiling the following with -fwarn-incomplete-patterns:

module Asdf where

f :: String -> Int
f "0" = 0

g :: Int -> Int
g 0 = 0

Yields:

asdf.hs:4:0:
    Warning: Pattern match(es) are non-exhaustive
             In the definition of `f':
                 Patterns not matched:
                     []
                     (GHC.Base.C# #x) : _ with #x `notElem` ['0']
                     (GHC.Base.C# '0') : (_ : _)

asdf.hs:7:0:
    Warning: Pattern match(es) are non-exhaustive
             In the definition of `g':
                 Patterns not matched: GHC.Base.I# #x with #x `notElem` [0#]

Losing the 'GHC.Base' stuff along with the various octothorpes would make the error messages a lot nicer. Ideally it'd be something like Patterns not matched: x where x notElem [0] for the second case, for instance.

Attachments (1)

Asdf.hs (73 bytes) - added by morabbin 7 years ago.
Exhibits problems described in #2204

Download all attachments as: .zip

Change History (10)

comment:1 Changed 12 years ago by simonpj

difficulty: Unknown
Milestone: _|_
Priority: normallow

Yes indeed. I think it'd make sense to do this as part of #595. Which is currently awaiting a keen author.

Simon

comment:2 Changed 12 years ago by ross

Type: proposalfeature request

comment:3 Changed 11 years ago by simonmar

Architecture: MultipleUnknown/Multiple

comment:4 Changed 11 years ago by simonmar

Operating System: MultipleUnknown/Multiple

comment:5 Changed 10 years ago by marcotmarcot

Cc: marcot@… added
Type of failure: None/Unknown

Changed 7 years ago by morabbin

Attachment: Asdf.hs added

Exhibits problems described in #2204

comment:6 Changed 6 years ago by simonpj

See also #5724 (closed as dup) for another report.

comment:7 Changed 5 years ago by thomie

Resolution: duplicate
Status: newclosed

Closing this as a duplicate of #8853, as that one has a more descriptive title ("Surprising mention of unboxed integers in pattern exhaustiveness warning") and a more recent error message.

comment:8 Changed 4 years ago by George Karachalias <george.karachalias@…>

In 8a506104/ghc:

Major Overhaul of Pattern Match Checking (Fixes #595)

This patch adresses several problems concerned with exhaustiveness and
redundancy checking of pattern matching. The list of improvements includes:

* Making the check type-aware (handles GADTs, Type Families, DataKinds, etc.).
  This fixes #4139, #3927, #8970 and other related tickets.

* Making the check laziness-aware. Cases that are overlapped but affect
  evaluation are issued now with "Patterns have inaccessible right hand side".
  Additionally, "Patterns are overlapped" is now replaced by "Patterns are
  redundant".

* Improved messages for literals. This addresses tickets #5724, #2204, etc.

* Improved reasoning concerning cases where simple and overloaded
  patterns are matched (See #322).

* Substantially improved reasoning for pattern guards. Addresses #3078.

* OverloadedLists extension does not break exhaustiveness checking anymore
  (addresses #9951). Note that in general this cannot be handled but if we know
  that an argument has type '[a]', we treat it as a list since, the instance of
  'IsList' gives the identity for both 'fromList' and 'toList'. If the type is
  not clear or is not the list type, then the check cannot do much still. I am
  a bit concerned about OverlappingInstances though, since one may override the
  '[a]' instance with e.g. an '[Int]' instance that is not the identity.

* Improved reasoning for nested pattern matching (partial solution). Now we
  propagate type and (some) term constraints deeper when checking, so we can
  detect more inconsistencies. For example, this is needed for #4139.

I am still not satisfied with several things but I would like to address at
least the following before the next release:
    Term constraints are too many and not printed for non-exhaustive matches
(with the exception of literals). This sometimes results in two identical (in
appearance) uncovered warnings. Unless we actually show their difference, I
would like to have a single warning.

comment:9 Changed 19 months ago by simonpj

Keywords: PatternMatchWarnings added
Note: See TracTickets for help on using tickets.