add note for non-exhaustive matches with guards

[ericmarkmartin]

Associated issue: #92197

When a match statement includes guards on every match arm (and is therefore necessarily non-exhaustive), add a note to the error E0004 diagnostic noting this.

[rustbot]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @fee1-dead (or someone else) soon.

Please see the contribution instructions for more information. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (S-waiting-on-review and S-waiting-on-author) stays updated, invoking these commands when appropriate:

• @rustbot author: the review is finished, PR author should check the comments and take action accordingly
• @rustbot review: the author is ready for a review, this PR will be queued again in the reviewer's queue

[rustbot]

Some changes might have occurred in exhaustiveness checking

cc @Nadrieril

[fee1-dead]

Could you please use translatable diagnostics?

[fee1-dead]

I think it would be better if the message pointed at the specific match arm that had guards and prevented the match from being exhaustive, but this is a step.

[fee1-dead]

why did you remove this comment?

[ericmarkmartin]

I thought that was in reference to the lack of the comments annotating the expected diagnostic in the compiletest. Is that not right?

[fee1-dead]

I think it was about the span that the diagnostic highlighted?

[fee1-dead]

Marking as waiting on author, pleasing make this a translatable diagnostic by using a struct and derive(Subdiagnostic). If you have any questions feel free to reach out on zulip.

@rustbot author

[ericmarkmartin]

I think it would be better if the message pointed at the specific match arm that had guards and prevented the match from being exhaustive, but this is a step.

How would you determine which match arm is preventing the match from being exhaustive? For instance in

fn foo(i: i32) {
    match i {
        i if i == 0 => {},
        i if i != 0 => {},
    }
}

removing either guard will cause the match to be exhaustive, and I feel like pointing to one of them in particular might be a bit confusing.

I also have some thoughts about how the error message could be improved---I mostly put this up so I could get some feedback there, though maybe Zulip is the better place to do that.

For instance, the current wording of the note makes it sound like something that would show up on any non-exhaustive match with an unguarded arm. I think this narrow concern could be addressed by explicitly mentioning that all arms have guards, like ocamlc does:

let foo (i : int) =
    match i with
    | i when i == 0 -> ()
    | i when i <> 0 -> ()

$ ocamlc main.ml
File "main.ml", lines 2-4, characters 4-25:
2 | ....match i with
3 |     | i when i == 0 -> ()
4 |     | i when i <> 0 -> ()
Warning 8 [partial-match]: this pattern-matching is not exhaustive.
All clauses in this pattern-matching are guarded.

[fee1-dead]

How would you determine which match arm is preventing the match from being exhaustive?

Obviously if we have the same pattern then they all don't contribute to exhaustiveness. I was thinking about how for specific cases like such:

    let x = Some(1);
    match x {
        Some(x) if x == 5 => {}
        None => {}
    }

we can then point at Some(x) if x == 5 and how that doesn't contribute to exhaustiveness.

    match x {
        Foo(x) if x == 5 => {}
        Foo(x) => {}
        Bar(x) if y == 42 => {}
        None => {}
    }

For the above we need to point at the Bar arm but not the Foo arm. this is definitely a complex algorithm if we don't have something like that already, but it could be recorded from exhaustiveness checking? I'm not sure. I'm happy to land this once you migrate to translatable diagnostics though.

[fee1-dead]

Thanks.

@bors r+ rollup

[bors]

📌 Commit 96bd056 has been approved by fee1-dead

It is now in the queue for this repository.