-
Notifications
You must be signed in to change notification settings - Fork 13.6k
Closed
Labels
A-diagnosticsArea: Messages for errors, warnings, and lintsArea: Messages for errors, warnings, and lintsC-bugCategory: This is a bug.Category: This is a bug.D-confusingDiagnostics: Confusing error or lint that should be reworked.Diagnostics: Confusing error or lint that should be reworked.F-non_exhaustive_omitted_patterns_lint`#![feature(non_exhaustive_omitted_patterns_lint)]``#![feature(non_exhaustive_omitted_patterns_lint)]`T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.Relevant to the compiler team, which will review and decide on the PR/issue.T-libs-apiRelevant to the library API team, which will review and decide on the PR/issue.Relevant to the library API team, which will review and decide on the PR/issue.
Milestone
Description
See #86809 (comment)
The non_exhaustive_omitted_patterns
lint exposes #[unstable]
and #[doc(hidden)]
variants.
E.g. for io::Error
:
error: some variants are not matched explicitly
--> src/main.rs:47:9
|
47 | _ => {}
| ^ pattern `Uncategorized` not covered
|
note: the lint level is defined here
--> src/main.rs:4:12
|
4 | #[deny(non_exhaustive_omitted_patterns)]
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
= help: ensure that all variants are matched explicitly by adding the suggested match arms
= note: the matched value is of type `ErrorKind` and the `non_exhaustive_omitted_patterns` attribute was found
But Uncategorized
is both hidden and unstable, and should not be considered part of the public api.
It'd be good to fix this before it hits stable in 1.57.
Metadata
Metadata
Assignees
Labels
A-diagnosticsArea: Messages for errors, warnings, and lintsArea: Messages for errors, warnings, and lintsC-bugCategory: This is a bug.Category: This is a bug.D-confusingDiagnostics: Confusing error or lint that should be reworked.Diagnostics: Confusing error or lint that should be reworked.F-non_exhaustive_omitted_patterns_lint`#![feature(non_exhaustive_omitted_patterns_lint)]``#![feature(non_exhaustive_omitted_patterns_lint)]`T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.Relevant to the compiler team, which will review and decide on the PR/issue.T-libs-apiRelevant to the library API team, which will review and decide on the PR/issue.Relevant to the library API team, which will review and decide on the PR/issue.
Activity
m-ou-se commentedon Sep 17, 2021
(cc @Nadrieril)
m-ou-se commentedon Sep 17, 2021
I'm not sure if the exact semantics for this lint in case of unstable and hidden variants have been discussed. E.g. whether it should only hide them when the enum comes from a different crate, or whether to warn about #[unstable] variants for which the #![feature] has been enabled.
Nadrieril commentedon Sep 17, 2021
Is there an enum in std that has
#[unstable]
variants but isn't#[non_exhaustive]
by any chance?EDIT: I grepped through
std
and there's onlyc_void
DevinR528 commentedon Sep 18, 2021
The problem is that
std::io::ErrorKind
, because it isnon_exhaustive
, triggers the lint with aNonExhaustive
constructor in the list of missing patterns so it will only ever say that it's missing_
(wildcard). This behavior has hidden the need to filter for these variants or care about them at all, as far as the enum lints go.I was able to get this to give me an odd warning but if you match on something that is the
c_void
type you either get_
wildcard because your match looks likematch c_void {}
or you have to turn on the feature so you can add a variant, which then the feature is on so it won't test either way.error E0423, when constructing the
c_void
enum without a variant givesSomething like this could be done to filter the witness in
is_useful
before we lint fornon_exhaustive_omitted_patterns
?As far as
doc(hidden)
since no other lints take this into account I don't see why this should. IMHO it seems like treating variants marked doc hidden any other way than simply ignoring their docs would be odd 🤷Nadrieril commentedon Sep 18, 2021
We'll want to completely ignore those variants even for exhaustiveness checking, so it's best to just not list unstable variants in
SplitWildcard::new()
.doc(hidden)
is more subtle because as you say we don't want to change the logic in that case. But I think we can still omit them from the lints. For that we can do like you did inapply_constructor
in your previous PR: filter out those variants from the witnesses list, and replace them with a_
.DevinR528 commentedon Sep 18, 2021
So if an enum (should we do struct fields too?) has a
doc(hidden)
attribute on a variant and is not crate local we now treat it like it'snon_exhaustive
and just return a witnesses list ofWildcard
?Will now give this for the first match (used to be
C
not_
)but this for the second
Nadrieril commentedon Sep 19, 2021
Yeah exactly! Thanks for the detailed example.
What do you think we should do for the following?
I think "patterns
B
and_
not covered" is better than just "pattern_
not covered" even though it looks a bit weird. Maybe "patternsB
and others not covered"?I didn't know we could
doc(hidden)
a struct field, but if so then we can do something similar there yeah.I don't feel competent to make that decision though. @m-ou-se do you know who I could ask something like that?
26 remaining items