-
Notifications
You must be signed in to change notification settings - Fork 12.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Report unreachable subpatterns consistently #120097
Report unreachable subpatterns consistently #120097
Conversation
This comment has been minimized.
This comment has been minimized.
7262077
to
0a9bb97
Compare
|
||
match res_void { | ||
Ok(_x) => {} | ||
Err(!), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, just double checking my understanding -- with exhaustive patterns, we don't need to care about never patterns b/c the scrutinee already disqualifies those patterns?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes. Said differently, never patterns are shorthand syntax: Err(!)
is short for Err(_) => unreachable_unchecked!()
. The rules for which arms are required are orthogonal, and here exhaustive_patterns
says "we don't need that arm". I've updated the tracking issue to clarify that while I was at it
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm
For T-lang: The following stable code now lints:
I assume this should deserve as much scrutiny from the compiler as the same pattern in a match arm, so it's totally justified to lint here. Just double checking that y'all agree with this. |
…ubpats, r=compiler-errors Report unreachable subpatterns consistently We weren't reporting unreachable subpatterns in function arguments and `let` expressions. This wasn't very important, but never patterns make it more relevant: a user might write `let (Ok(x) | Err(!)) = ...` in a case where `let Ok(x) = ...` is accepted, so we should report the `Err(!)` as redundant. r? `@compiler-errors`
…ubpats, r=compiler-errors Report unreachable subpatterns consistently We weren't reporting unreachable subpatterns in function arguments and `let` expressions. This wasn't very important, but never patterns make it more relevant: a user might write `let (Ok(x) | Err(!)) = ...` in a case where `let Ok(x) = ...` is accepted, so we should report the `Err(!)` as redundant. r? ``@compiler-errors``
…iaskrgr Rollup of 11 pull requests Successful merges: - rust-lang#117910 (Refactor uses of `objc_msgSend` to no longer have clashing definitions) - rust-lang#118639 (Undeprecate lint `unstable_features` and make use of it in the compiler) - rust-lang#119801 (Fix deallocation with wrong allocator in (A)Rc::from_box_in) - rust-lang#120058 (bootstrap: improvements for compiler builds) - rust-lang#120059 (Make generic const type mismatches not hide trait impls from the trait solver) - rust-lang#120097 (Report unreachable subpatterns consistently) - rust-lang#120137 (Validate AggregateKind types in MIR) - rust-lang#120164 (`maybe_lint_impl_trait`: separate `is_downgradable` from `is_object_safe`) - rust-lang#120181 (Allow any `const` expression blocks in `thread_local!`) - rust-lang#120204 (Builtin macros effectively have implicit #[collapse_debuginfo(yes)]) - rust-lang#120218 (rustfmt: Check that a token can begin a nonterminal kind before parsing it as a macro arg) r? `@ghost` `@rustbot` modify labels: rollup
…iaskrgr Rollup of 10 pull requests Successful merges: - rust-lang#117910 (Refactor uses of `objc_msgSend` to no longer have clashing definitions) - rust-lang#118639 (Undeprecate lint `unstable_features` and make use of it in the compiler) - rust-lang#119801 (Fix deallocation with wrong allocator in (A)Rc::from_box_in) - rust-lang#120058 (bootstrap: improvements for compiler builds) - rust-lang#120059 (Make generic const type mismatches not hide trait impls from the trait solver) - rust-lang#120097 (Report unreachable subpatterns consistently) - rust-lang#120137 (Validate AggregateKind types in MIR) - rust-lang#120164 (`maybe_lint_impl_trait`: separate `is_downgradable` from `is_object_safe`) - rust-lang#120181 (Allow any `const` expression blocks in `thread_local!`) - rust-lang#120218 (rustfmt: Check that a token can begin a nonterminal kind before parsing it as a macro arg) r? `@ghost` `@rustbot` modify labels: rollup
Rollup merge of rust-lang#120097 - Nadrieril:consistent_unreachable_subpats, r=compiler-errors Report unreachable subpatterns consistently We weren't reporting unreachable subpatterns in function arguments and `let` expressions. This wasn't very important, but never patterns make it more relevant: a user might write `let (Ok(x) | Err(!)) = ...` in a case where `let Ok(x) = ...` is accepted, so we should report the `Err(!)` as redundant. r? ```@compiler-errors```
We weren't reporting unreachable subpatterns in function arguments and
let
expressions. This wasn't very important, but never patterns make it more relevant: a user might writelet (Ok(x) | Err(!)) = ...
in a case wherelet Ok(x) = ...
is accepted, so we should report theErr(!)
as redundant.r? @compiler-errors