-Wincomplete-uni-patterns should not warn about explicitly-marked irrefutable patterns

changed weight to 5

added Tfeature request Trac import labels

added Pnormal label

It seems the opposite of this in implemented in GHC 9.2.1:

f :: IO (Maybe a) -> IO a
f x = do
  ~(Just y) <- x
  pure y

main :: IO ()
main = do
  x <- f (pure Nothing)
  print (x :: Int)

$ ghc -Wall --make test1.hs
[1 of 1] Compiling Main             ( test1.hs, test1.o )

test1.hs:3:3: warning: [-Wincomplete-uni-patterns]
    Pattern match(es) are non-exhaustive
    In a pattern binding:
        Patterns of type ‘Maybe a’ not matched: Nothing
  |
3 |   ~(Just y) <- x
  |   ^^^^^^^^^^^^^^
Linking test1 ...

But changing f to:

f :: IO (Maybe a) -> IO a
f x = do
  Just y <- x
  pure y

results in no warning:

$ ghc -Wall --make test2.hs
[1 of 1] Compiling Main             ( test2.hs, test2.o )
Linking test2 ...

GHC 9.0.1 produces no warning for either.

Hm, now that I think about this a bit more, it's probably all right. An irrefutable pattern means the error cannot be reported using the MonadFail instance and would just error later when the thunk is evaluated. And that's not what I want in this case. So this is a good warning!

added pattern match warnings label

The fact the match is partial is explicit and visible with the ~ syntax

But this isn't true. There are good reasons to write things like f ~(x,y) = _, even though (x,y) is not partial. Consider code like this:

data Foo = Foo Int Bool

f = do
    ~(Foo x y) <- get
    put $ Foo (x + 1) (not y)

It's not partial. Then later someone comes along and changes the first line to data Foo = Foo Int Bool | Bar String. Now the code is partial, and if we made this change, then there'd be no warning that it's now partial.

It used to be that lazy matching with ~(Just x) on the lhs silenced the coverage checker. This seems indeed be changed in 9.2.1. I cannot find it on the changelog for 9.2.1 though, (or did I grep for the wrong things?).

There's something funny here.

If I say f ~(Just x) = 5, that function is safe to call with any argument. It will never error. And yet it seems a compile-time warning will appear. I think what I'm saying is that the pattern-match there is complete and should never warn... but a use of x on the RHS is potentially troublesome. Using x is somewhat like using a partial record selector. (Actually, very like a partial record selector. Indeed, x is exactly like an applied partial record selector.) So maybe some reshuffling is in order here.

This doesn't actually address the desire to be able to suppress the warnings, though, unless @abel is happy to disable warnings on partial record selectors.

Richard @rae is right, foo ~(Bar x y z) = e would most correctly only warn about partial projection for the occurrences of x, y, z in e. Maybe there would be some logistics needed to collect warnings for occurrences coming from a single match in one umbrella warning, so the user is not spammed with repetition (and also can understand better the origin of the partial projections). [But I am side tracking from the main issue here.]

Sadly, I don't see any warning in GHC for the use of a partial record selectors. I do see a warning for the definition of a partial field, but that's different.

So I think this is a request for a new warning -- use of a variable from a potentially incorrect lazy pattern -- along with a tweak to incomplete-uni-patterns to exclude lazy pattern matches.

Trac field	Value
Version	8.2.2
Type	FeatureRequest
TypeOfFailure	OtherFailure
Priority	normal
Resolution	Unresolved
Component	Compiler
Test case
Differential revisions
BlockedBy
Related
Blocking
CC
Operating system
Architecture

-Wincomplete-uni-patterns should not warn about explicitly-marked irrefutable patterns

Child items 0

Activity