mutually exclusive match arms with `if` cases are not recognized to be covering

[drahnr]

I tried this code:

enum Foo {
    A(bool),
    B,
    C,
}


fn main() {

    let a = Foo::A(false);
    match a {
        Foo::A(x) if x => {},
        Foo::A(x) if !x => {},
        Foo::B => {},
        Foo::C => {},
    }
}

https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=b70f6933b22baa139e9ad679a7559935

I expected to see this happen: Compilation without an error

Instead, this happened: Rustc wants a catch-all for Foo::A(_), which is not required since the other match arms are covering.

Compiling playground v0.0.1 (/playground)
error[[E0004]](https://doc.rust-lang.org/stable/error-index.html#E0004): non-exhaustive patterns: `A(_)` not covered
  [--> src/main.rs:12:11
](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=b70f6933b22baa139e9ad679a7559935#)   |
2  | / enum Foo {
3  | |     A(bool),
   | |     - not covered
4  | |     B,
5  | |     C,
6  | | }
   | |_- `Foo` defined here
...
12 |       match a {
   |             ^ pattern `A(_)` not covered
   |
   = help: ensure that all possible cases are being handled, possibly by adding wildcards or more match arms
   = note: the matched value is of type `Foo`

For more information about this error, try `rustc --explain E0004`.
error: could not compile `playground` due to previous error

Meta

rustc --version --verbose:

1.58.1

[leonardo-m]

I think that currently rustc bails totally out of the analysis when there's an if among the branches. This is simplistic but it's also easy for the programmer to remember and understand. If we start adding special cases like this one, the programmer has more to remember. This is a cost.

How much frequent are cases like this where there are two branches with opposite tests? I think they are sufficiently common, but some data could be useful.

[drahnr]

What kind of data would you like to collect? Depending on the implementer, this could be circumvented in various ways. Technically the second match arm could just drop the if, but for clarity it's better to be explicit.

I don't see this really as a bug per se, the error message just surprised me.

[fmease]

I don't see this really as a bug per se, the error message just surprised me.

Would you like the compiler to add a note that the overlap analysis is conservative and does not inspect guards?

Or maybe just adding a small hint, something like:

   error[E0004]: non-exhaustive patterns: `A(_)` not covered
     --> src/main.rs:12:11
      |
   2  | / enum Foo {
   3  | |     A(bool),
      | |     - not covered
   4  | |     B,
   5  | |     C,
   6  | | }
      | |_- `Foo` defined here
   ...
   12 |       match a {
      |             ^ pattern `A(_)` not covered
+  ...
+  15 |           Foo::A(x) if !x => {},
+     |                     ----- possibly false
      |
      = help: ensure that all possible cases are being handled, possibly by adding wildcards or more match arms
      = note: the matched value is of type `Foo`

Not sure if that will help, it's only a minor useless(?) change. I refrained from adding anything else like note: the overlap check is conservative and does not look at guards or possibly false; guards may be false in general since rustc doesn't do it anywhere else either. Type systems (including ownership systems) are conservative by nature and disallow certain programs which may be deemed correct in an untyped context (Rice's Theorem yadda yadda).

Consider the related case of initialization:

let x;
if true { x = 10; }
dbg!(x);

This will be rejected with error: use of possibly-uninitialized variable: `x` even though the condition will always be true. It's the same story. No extra note.

[drahnr]

Fair point, feel free to close this

[fmease]

Although my comment kind of argues against improving the error message, confusing error messages are officially considered bugs in rustc, so I am split on this one. I'd like to see it made better but I am not entirely sure how exactly. Maybe someone else has a suggestion.

[scottmcm]

I'll add that this is completely consistent with the behaviour of if outside of match too -- if b {} else if !b {} is not exhaustive either.

Remember that arms are checked in order, so the exhaustive way to write this is just

    match a {
        Foo::A(x) if x => {},
        Foo::A(x) => {},
        Foo::B => {},
        Foo::C => {},
    }

exactly like how the way to write the above if is if b {} else {} (without the if !b).