Wrong overlapped/missing pattern warnings
compiling:
module Overlap where
f (n+1) = 2
f 0 = 1
emits wrongly:
Warning: Pattern match(es) are overlapped
In the definition of `f': f 0 = ...
The Patterns are disjoint, aren't they? At least "f 0"
yields "1" when evaluated and negative inputs for f are
rejected. However the warning is not emitted if the two
equations are given in reversed order.
Christian (maeder@tzi.de)
Activity
added Tbug Trac import parser labels
Logged In: YES user_id=50165 Here's another example, from Peter White When I compile the following module with the -Wall option on ghc v6.2.1 I get warnings: Warning: Pattern match(es) are non-exhaustive In a record-update construct: Patterns not matched D2. The warnings occur at both of the indicated places in the module. Since the functions both handle all the cases of the data type D, it seems the warning should not be given. data D = D1 { f1 :: Int } | D2 -- Use pattern matching in the argument f :: D -> D f d1@(D1 {f1 = n}) = d1 { f1 = f1 d1 + 1 } -- Warning here f d = d -- Use case pattern matching g :: D -> D g d1 = case d1 of D1 { f1 = n } -> d1 { f1 = n + 1 } -- Warning here also D2 -> d1Logged In: YES user_id=50165 Another example from Neil Mitchell I have been playing around with -fwarn-incomplete-patterns under GHC 6.4.1 on Windows. -- no warning ex1 x = ss where (s:ss) = x -- no warning ex2 x = let (s:ss) = x in ss -- Warning: Pattern match(es) are non-exhaustive -- In a case alternative: Patterns not matched: [] ex3 x = case x of ~(s:ss) -> ss I have translated all 3 functions using the rules supplied in the Haskell 98 report, so they all have the same meaning, but only one gives an error. Is it intentional to ignore where/let pattern matches?Logged In: YES user_id=618575 When adding -fwarn-simple-patterns to the command line, all 3 of the previous examples give an additional 2 warning's, i.e. ex1 and ex2 give two identical warnings, and ex3 gives 3 identical warnings. Warning: Pattern match(es) are non-exhaustive In a case alternative: Patterns not matched: []Logged In: YES user_id=50165 Another example, this time from John Meacham the following gives a 'non-exhaustive pattern matching' error when it shouldn't. the ~-pattern always matches. It is not the function that is non-exhausitive, but the irrefutable binding, which are necessarily always non- exhausive so warning about it is the wrong thing to do. f :: [a] -> a f [x] = x f ~(_:xs) = f xsThe problems with irrefutable patterns are now fixed (see also #827 (closed)).
Trac metadata
Trac field Value Component Compiler (Parser) → Compiler Operating system - → Unknown Architecture - → Unknown removed parser label
added Plow label
mentioned in commit ed57d1b2
mentioned in commit 060f50ec
mentioned in commit 64489a6c
mentioned in commit fe10eb1a
mentioned in commit 22ee1c07
mentioned in commit 7df76d91
mentioned in commit 09eeb2c9
mentioned in commit 1ea23696
mentioned in commit 63de8a92
mentioned in commit 1d958da9
mentioned in commit 24d83194
mentioned in commit dfc4093c
mentioned in commit 65c6ba14
mentioned in commit 2e2760b4
mentioned in commit 643b1dae
mentioned in commit 2222f5f8
mentioned in commit ac5c6a24
mentioned in commit 023b15b3
mentioned in commit abfd87a5
mentioned in commit 33b6850a
mentioned in commit c6a7dad9
mentioned in commit 568c8bfc
mentioned in commit 1ed5d1ed
mentioned in commit 35334ae7
mentioned in commit 8b2f70a2
