match exhaustiveness: Show the guard exhaustivity note only when it's the guards alone that cause non-exhaustiveness by jakubadamw · Pull Request #154938 · rust-lang/rust

jakubadamw · 2026-04-07T09:17:38Z

Only show the "match arms with guards don't count towards exhaustivity" note when removing all guards would make the match exhaustive, but also in the cases when the match contains arms without guards. Previously, this note was shown only if all arms had guards, but even if the patterns themselves were insufficient to cover all valid values of a type.

Do this by rerunning the exhaustiveness analysis with guards stripped to determine whether the guards are actually the cause of non-exhaustiveness. This only happens on an actual exhaustiveness error, so should not be a performance concern.

This will make a program like:

fn main() {
    let some_condition = true;
    let some_option: Option<u8> = None;

    let _res = match some_option {
        Some(val) if some_condition => val,
        None => 0,
    };
}

produce the note ”match arms with guards don't count towards exhaustivity” that previously would not have been appearing.

Closes #104653 as I think this addresses the spirit of that issue. I don’t believe it’s necessary to be any more elaborate in the diagnostics here?

… cause non-exhaustiveness Only show the "match arms with guards don't count towards exhaustivity" note when removing all guards would make the match exhaustive. Previously, this note was shown whenever all arms had guards, even if the patterns themselves were insufficient to cover all valid values of a type. Re-run the exhaustiveness analysis with guards stripped to determine whether the guards are actually the cause of non-exhaustiveness. This only happens on an actual exhaustiveness error, so should not be a performance concern.

rustbot · 2026-04-07T09:17:41Z

Some changes occurred in match checking

cc @Nadrieril

rustbot · 2026-04-07T09:17:44Z

r? @wesleywiser

rustbot has assigned @wesleywiser.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

Owners of files modified in this PR: compiler
compiler expanded to 69 candidates
Random selection from 11 candidates

Nadrieril · 2026-04-08T10:05:07Z

r? me

Gha mixed feelings about running exhaustiveness twice... The diagnostic change is really nice tho, and it's in an error path, so why not.

The current message seems fine to me, don't think more details would be particularly needed.

@bors r+ rollup

rust-bors · 2026-04-08T10:05:10Z

📌 Commit db8ce5f has been approved by Nadrieril

It is now in the queue for this repository.

match exhaustiveness: Show the guard exhaustivity note only when it's the guards alone that cause non-exhaustiveness Only show the "match arms with guards don't count towards exhaustivity" note when removing all guards would make the match exhaustive, but also in the cases when some arms don’t have guards. Previously, this note was shown whenever all arms had guards, but even if the patterns themselves were insufficient to cover all valid values of a type. Do this by rerunning the exhaustiveness analysis with guards stripped to determine whether the guards are actually the cause of non-exhaustiveness. This only happens on an actual exhaustiveness error, so should not be a performance concern. This will make a program like: ```rust fn main() { let some_condition = true; let some_option: Option<u8> = None; let _res = match some_option { Some(val) if some_condition => val, None => 0, }; } ``` produce the note ”match arms with guards don't count towards exhaustivity” that previously would not have been appearing. Closes rust-lang#104653 as I think this addresses the spirit of that issue. I don’t believe it’s necessary to be any more elaborate in the diagnostics here?

…uwer Rollup of 15 pull requests Successful merges: - #153995 (Use convergent attribute to funcs for GPU targets) - #154184 (stabilize s390x vector registers) - #151898 (constify DoubleEndedIterator) - #154235 (remove unnecessary variables and delimiter check) - #154473 (move borrow checker tests) - #154745 (Replace span_look_ahead with span_followed_by) - #154778 (make field representing types invariant over the base type) - #154867 (Fix private fields diagnostics and improve error messages) - #154879 (Don't store `pattern_ty` in `TestableCase`) - #154910 (Suppress `unreachable_code` lint in `derive(PartialEq, Clone)`) - #154923 (Fix ICE in next-solver dyn-compatibility check) - #154934 (Add getters for `rustc_pattern_analysis::constructor::Slice` fields) - #154938 (match exhaustiveness: Show the guard exhaustivity note only when it's the guards alone that cause non-exhaustiveness) - #154961 (Use derived impl for `GappedRange` subdiagnostic) - #154980 (rustc-dev-guide subtree update)

Rollup merge of #154938 - jakubadamw:issue-104653, r=Nadrieril match exhaustiveness: Show the guard exhaustivity note only when it's the guards alone that cause non-exhaustiveness Only show the "match arms with guards don't count towards exhaustivity" note when removing all guards would make the match exhaustive, but also in the cases when the match contains arms without guards. Previously, this note was shown only if all arms had guards, but even if the patterns themselves were insufficient to cover all valid values of a type. Do this by rerunning the exhaustiveness analysis with guards stripped to determine whether the guards are actually the cause of non-exhaustiveness. This only happens on an actual exhaustiveness error, so should not be a performance concern. This will make a program like: ```rust fn main() { let some_condition = true; let some_option: Option<u8> = None; let _res = match some_option { Some(val) if some_condition => val, None => 0, }; } ``` produce the note ”match arms with guards don't count towards exhaustivity” that previously would not have been appearing. Closes #104653 as I think this addresses the spirit of that issue. I don’t believe it’s necessary to be any more elaborate in the diagnostics here?

…uwer Rollup of 15 pull requests Successful merges: - rust-lang/rust#153995 (Use convergent attribute to funcs for GPU targets) - rust-lang/rust#154184 (stabilize s390x vector registers) - rust-lang/rust#151898 (constify DoubleEndedIterator) - rust-lang/rust#154235 (remove unnecessary variables and delimiter check) - rust-lang/rust#154473 (move borrow checker tests) - rust-lang/rust#154745 (Replace span_look_ahead with span_followed_by) - rust-lang/rust#154778 (make field representing types invariant over the base type) - rust-lang/rust#154867 (Fix private fields diagnostics and improve error messages) - rust-lang/rust#154879 (Don't store `pattern_ty` in `TestableCase`) - rust-lang/rust#154910 (Suppress `unreachable_code` lint in `derive(PartialEq, Clone)`) - rust-lang/rust#154923 (Fix ICE in next-solver dyn-compatibility check) - rust-lang/rust#154934 (Add getters for `rustc_pattern_analysis::constructor::Slice` fields) - rust-lang/rust#154938 (match exhaustiveness: Show the guard exhaustivity note only when it's the guards alone that cause non-exhaustiveness) - rust-lang/rust#154961 (Use derived impl for `GappedRange` subdiagnostic) - rust-lang/rust#154980 (rustc-dev-guide subtree update)

jakubadamw added 2 commits April 7, 2026 10:08

Update results for tests affected by the change

db8ce5f

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Apr 7, 2026

rustbot assigned wesleywiser Apr 7, 2026

rustbot assigned Nadrieril and unassigned wesleywiser Apr 8, 2026

rust-bors Bot added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Apr 8, 2026

This was referenced Apr 8, 2026

Rollup of 9 pull requests #154983

Closed

Rollup of 15 pull requests #154985

Merged

rust-bors Bot merged commit 6b8320f into rust-lang:main Apr 8, 2026
11 checks passed

rustbot added this to the 1.96.0 milestone Apr 8, 2026

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

match exhaustiveness: Show the guard exhaustivity note only when it's the guards alone that cause non-exhaustiveness#154938

match exhaustiveness: Show the guard exhaustivity note only when it's the guards alone that cause non-exhaustiveness#154938
rust-bors[bot] merged 2 commits intorust-lang:mainfrom
jakubadamw:issue-104653

jakubadamw commented Apr 7, 2026 •

edited

Loading

Uh oh!

rustbot commented Apr 7, 2026

Uh oh!

rustbot commented Apr 7, 2026

Uh oh!

Nadrieril commented Apr 8, 2026

Uh oh!

rust-bors Bot commented Apr 8, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Uh oh!

Conversation

jakubadamw commented Apr 7, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rustbot commented Apr 7, 2026

Uh oh!

rustbot commented Apr 7, 2026

Uh oh!

Nadrieril commented Apr 8, 2026

Uh oh!

rust-bors Bot commented Apr 8, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

jakubadamw commented Apr 7, 2026 •

edited

Loading