-
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
Tracking Issue for #![feature(non_exhaustive_omitted_patterns_lint)]
#89554
Comments
This comment was marked as resolved.
This comment was marked as resolved.
In terms of the "documentation" bullet-point, the lint should turn up automatically on that list and I think that's enough. So we'll only need to check that it says the right thing once we've ironed out the name and message etc. |
The question about not filtering I'm also curious about the stability of warning/error messages, I assume rust makes no guarantee so they can be improved quickly. |
Yeah, don't think there's any formal guarantee and they do change in small ways regularly |
Fix exposing fields marked unstable or doc hidden Closes rust-lang#89837 Work towards rust-lang#89554 Filter fields that are marked `doc(hidden)` or are unstable with that feature turned off. This brings structs and enums into alignment behavior-wise when emitting warning/errors about pattern exhaustiveness/reachability. cc `@Nadrieril`
Update everything to latest except for nix. In nix v0.23, a number of enums were marked #[non_exhaustive] (nix-rust/nix#1474). Since we want exhaustive matches in some cases, we will use v0.22 until non_exhaustive_omitted_patterns_lint is stablized (rust-lang/rust#89554)
Update everything to latest except for nix. In nix v0.23, a number of enums were marked #[non_exhaustive] (nix-rust/nix#1474). Since we want exhaustive matches in some cases, we will use v0.22 until non_exhaustive_omitted_patterns_lint is stablized (rust-lang/rust#89554)
Update everything to latest except for nix. In nix v0.23, a number of enums were marked #[non_exhaustive] (nix-rust/nix#1474). Since we want exhaustive matches in some cases, we will use v0.22 until non_exhaustive_omitted_patterns_lint is stablized (rust-lang/rust#89554)
Update everything to latest except for nix. In nix v0.23, a number of enums were marked #[non_exhaustive] (nix-rust/nix#1474). Since we want exhaustive matches in some cases, we will use v0.22 until non_exhaustive_omitted_patterns_lint is stablized (rust-lang/rust#89554)
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
I think I've come up with a better name for the lint: what about |
This comment was marked as off-topic.
This comment was marked as off-topic.
I don't have strong feelings either way, so whatever the outcome, I'll like it 😄 . My thought about |
I like your suggestion! |
I would like to file a complaint about the lint message here, unsure if you would want a separate bug report. Currently, I get the following error message:
This error message is correct, but not helpful, and confused the person writing the pull request who hit this issue. It does not show what the variants are or where the match is. I would file a repro but I'm fairly sure non_exhaustive is ignored in the same crate, so it would not be doable on playground. |
Hmm, it does seem like a bug that no source code is shown. Can you file an issue? I'm not sure I followed why the MCVE wouldn't be possible, but if you could provide something like that, that would be helpful. |
Sure. An MVCE is possible, but non_exhaustive is only enforced when the non_exhaustive item is in a separate crate, so it just can't be a playground. |
Ah, I see what you mean. Yeah, an MCVE would be good even if it can't be on the playground. |
error: unknown lint: `non_exhaustive_omitted_patterns` --> impl/src/declaration.rs:297:43 | 297 | #[cfg_attr(all(test, exhaustive), deny(non_exhaustive_omitted_patterns))] | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | = note: the `non_exhaustive_omitted_patterns` lint is unstable = note: see issue #89554 <rust-lang/rust#89554> for more information = help: add `#![feature(non_exhaustive_omitted_patterns_lint)]` to the crate attributes to enable = note: `-D unknown-lints` implied by `-D warnings`
I just realized that there is a pretty fundamental limitation with this lint. Observe the following two cases: #![deny(non_exhaustive_omitted_patterns)]
match (&x, true) {
(NonExhaustiveEnum::A, true) => {}
_ => {} // detected
}
match (true, &x) {
(true, NonExhaustiveEnum::A) => {}
_ => {} // not detected
} The second is not detected because in the exhaustiveness checker as soon as we figure out that An alternative would be a more naive version that doesn't interact with exhaustiveness. It would just check that each column mentions all variants. This means it would not trigger on the following, which we initially wanted. This feels fine to me. #[deny(non_exhaustive_omitted_patterns)]
match foo {
Alphabet::A => {}
Alphabet::B if guard => {}
_ => {}
} EDIT: in fact since this doesn't interact with exhaustiveness it can be a clippy lint, which feels more appropriate |
#116734 changed the behavior of the lint to match what I proposed above |
Note: the lint level can no longer be put on a match arm, it needs to be on the whole match. This is a silent breaking change. I thought it was ok because the feature is unstable, but turns out EDIT: did that in #117094 |
Warn users who set `non_exhaustive_omitted_patterns` lint level on a match arm Before rust-lang#116734, the recommended usage of the [`non_exhaustive_omitted_patterns` lint](rust-lang#89554) was: ```rust match Bar::A { Bar::A => {}, #[warn(non_exhaustive_omitted_patterns)] _ => {}, } ``` After rust-lang#116734 this no longer makes sense, and recommended usage is now: ```rust #[warn(non_exhaustive_omitted_patterns)] match Bar::A { Bar::A => {}, _ => {}, } ``` As you can guess, this silently breaks all uses of the lint that used the previous form. This is a problem in particular because `syn` recommends usage of this lint to its users in the old way. This PR emits a warning when the previous form is used so users can update. r? `@cjgillot`
Warn users who set `non_exhaustive_omitted_patterns` lint level on a match arm Before rust-lang#116734, the recommended usage of the [`non_exhaustive_omitted_patterns` lint](rust-lang#89554) was: ```rust match Bar::A { Bar::A => {}, #[warn(non_exhaustive_omitted_patterns)] _ => {}, } ``` After rust-lang#116734 this no longer makes sense, and recommended usage is now: ```rust #[warn(non_exhaustive_omitted_patterns)] match Bar::A { Bar::A => {}, _ => {}, } ``` As you can guess, this silently breaks all uses of the lint that used the previous form. This is a problem in particular because `syn` recommends usage of this lint to its users in the old way. This PR emits a warning when the previous form is used so users can update. r? `@cjgillot`
I discovered something cool today: #[warn(non_exhaustive_omitted_patterns)]
match (x, y) {
(Enum::A, Enum::A) => true,
(Enum::B, Enum::B) => true,
_ => false,
} I kind of want this for arbitrary enums now. |
Maybe this could be a general |
This is a tracking issue for the
non_exhaustive_omitted_patterns
lint.The feature gate for the issue is
#![feature(non_exhaustive_omitted_patterns_lint)]
.About tracking issues
Tracking issues are used to record the overall progress of implementation.
They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.
Steps
Unresolved Questions
Implementation history
non_exhaustive_omitted_patterns
lint exposes unstable and hidden fields #89837non_exhaustive_omitted_patterns
by columns #116734non_exhaustive_omitted_patterns
lint level on a match arm #117094The text was updated successfully, but these errors were encountered: