Tracking Issue for #![feature(non_exhaustive_omitted_patterns_lint)] #89554
Description
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
- Set a feature gate Feature gate the non_exhaustive_omitted_patterns lint #89428Clippy false positive False positive in match_same_arms + non_exhaustive_omitted_patterns rust-clippy#10327
matches!false positive False positive in non_exhaustive_omitted_patterns:matches!#135137Stabilization PR (see instructions on rustc-dev-guide)
Unresolved Questions
- Lint name is potentially unclear New non_exhaustive_omitted_patterns lint exposes unstable and hidden enum variants. #89042 (comment)Lint message needs to be improved Feature gate the non_exhaustive_omitted_patterns lint #89428 (comment)
Implementation history
- ICE was discovered in ICE related to non_exhaustive_omitted_patterns lint #89382 and fixed Fix ICE caused by non_exaustive_omitted_patterns struct lint #89423Feature gate PR Feature gate the non_exhaustive_omitted_patterns lint #89428Filter out unstable/hidden fields too
non_exhaustive_omitted_patternslint exposes unstable and hidden fields #89837Rework the lint to make it more consistent Lintnon_exhaustive_omitted_patternsby columns #116734Warn users to not set the lint level on a single arm as was previously recommended Warn users who setnon_exhaustive_omitted_patternslint level on a match arm #117094
Metadata
Metadata
Assignees
Labels
Relating to exhaustiveness / usefulness checking of patternsArea: Lints (warnings about flaws in source code) such as unused_mut.Category: An issue tracking the progress of sth. like the implementation of an RFC`#![feature(non_exhaustive_omitted_patterns_lint)]`Status: This is ready to stabilize; it may need a stabilization report and a PRRelevant to the language team
Type
Projects
Milestone
Relationships
Development
No branches or pull requests
Participants
Activity
DevinR528 commentedon Oct 7, 2021
Nadrieril commentedon Oct 11, 2021
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.
DevinR528 commentedon Oct 13, 2021
The question about not filtering
doc(hidden)(and maybe this was only me feeling like it was odd) is kind of resolved for me since we unified the behavior so I no longer have the argument that filteringdoc(hidden)variants/fields out of error and warning messages is not the norm (now it is done for all exhaustiveness checking).I'm also curious about the stability of warning/error messages, I assume rust makes no guarantee so they can be improved quickly.
Nadrieril commentedon Oct 13, 2021
Yeah, don't think there's any formal guarantee and they do change in small ways regularly
30 remaining items
Nadrieril commentedon Oct 23, 2023
#116734 changed the behavior of the lint to match what I proposed above
Nadrieril commentedon Oct 23, 2023
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
synis using the lint and recommending to put the lint level on the match arm. I'll try to make the breaking change not silent at least.EDIT: did that in #117094
#[non_exhaustive]) #69930non_exhaustive_omitted_patternslint level on a match arm #117094Auto merge of rust-lang#117094 - Nadrieril:warn-lint-on-arm, r=<try>
Auto merge of rust-lang#117094 - Nadrieril:warn-lint-on-arm, r=cjgillot
..(rest) in struct pattern (StructPatternEtCetera) #81282Nadrieril commentedon Dec 8, 2023
I discovered something cool today:
non_exhaustive_omitted_patternswill warn in the following case if we add variants toEnum, which an exhaustiveness-based check wouldn't catch:I kind of want this for arbitrary enums now.
Nadrieril commentedon Dec 8, 2023
Maybe this could be a general
#[warn(mention_all_variants_of(Enum))]matches!#135137dtolnay commentedon Jan 5, 2025
There is a false positive involving the standard library
matches!macro: #135137