Tracking Issue for #![feature(non_exhaustive_omitted_patterns_lint)]

[Nadrieril]

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

• Implemented in Add non_exhaustive_omitted_patterns lint related to rfc-2008-non_exhaustive #86809
• Set a feature gate Feature gate the non_exhaustive_omitted_patterns lint #89428
• Adjust documentation (see instructions on rustc-dev-guide) — https://doc.rust-lang.org/rustc/lints/listing/allowed-by-default.html#non-exhaustive-omitted-patterns
• Clippy false positive False positive in match_same_arms + non_exhaustive_omitted_patterns rust-clippy#10327
• Stabilization 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

• Implemented in Add non_exhaustive_omitted_patterns lint related to rfc-2008-non_exhaustive #86809
• 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 #89423
• Feature gate PR Feature gate the non_exhaustive_omitted_patterns lint #89428
• A bug was discovered in New non_exhaustive_omitted_patterns lint exposes unstable and hidden enum variants. #89042 and fixed Fix: non_exhaustive_omitted_patterns by filtering unstable and doc hidden variants #89105
• Filter out unstable/hidden fields too non_exhaustive_omitted_patterns lint exposes unstable and hidden fields #89837
• Rework the lint to make it more consistent Lint non_exhaustive_omitted_patterns by columns #116734
• Warn users to not set the lint level on a single arm as was previously recommended Warn users who set non_exhaustive_omitted_patterns lint level on a match arm #117094

[Nadrieril]

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]

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 filtering doc(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]

Yeah, don't think there's any formal guarantee and they do change in small ways regularly

[Kampfkarren]

I would like to move forward on this as we are currently using this in selene, but gated by nightly-only CI.

The "Lint message needs to be improved" is doable.

Unsure how the lint name could be improved. CC @camelid since you brought up the concern

[camelid]

I think I've come up with a better name for the lint: what about non_exhaustive_wildcards or wildcards_for_non_exhaustive? Then denying it would look like #[deny(non_exhaustive_wildcards)] or #[deny(wildcards_for_non_exhaustive)]. I think that is more self-explanatory.

[DevinR528]

I don't have strong feelings either way, so whatever the outcome, I'll like it 😄 . My thought about non_exhaustive_wildcards is that it sounds like you are forbidding the use of wildcards. What about #[deny(missing_non_exhaustive_patterns)]?

[camelid]

I like your suggestion!

[Kampfkarren]

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:

error: some variants are not matched explicitly
   |
note: the lint level is defined here
  --> selene-lib/src/rules/high_cyclomatic_complexity.rs:77:14
   |
77 |         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 `full_moon::ast::Value` and the `non_exhaustive_omitted_patterns` attribute was found

error: some variants are not matched explicitly
  |
  = help: ensure that all variants are matched explicitly by adding the suggested match arms
  = note: the matched value is of type `full_moon::ast::Expression` and the `non_exhaustive_omitted_patterns` attribute was found

error: some variants are not matched explicitly
    |
note: the lint level is defined here
   --> selene-lib/src/rules/high_cyclomatic_complexity.rs:180:18
    |
180 |             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 `full_moon::ast::Stmt` and the `non_exhaustive_omitted_patterns` attribute was found

error: could not compile `selene-lib` due to 3 previous errors

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.

[camelid]

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.

[Kampfkarren]

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.

[camelid]

Ah, I see what you mean. Yeah, an MCVE would be good even if it can't be on the playground.

[Nadrieril]

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 (false, _) makes the second branch reachable, we don't analyze it further. Something similar would happen with a Some(NonExhaustiveEnum::A) pattern.
In order for this lint to work properly with nested patterns, we would need to change the exhaustiveness algorithm to explore a lot more cases, which isn't feasible performance-wise.

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

[Nadrieril]

#116734 changed the behavior of the lint to match what I proposed above

[Nadrieril]

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 syn is 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

[Nadrieril]

I discovered something cool today: non_exhaustive_omitted_patterns will warn in the following case if we add variants to Enum, which an exhaustiveness-based check wouldn't catch:

#[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.

[Nadrieril]

Maybe this could be a general #[warn(mention_all_variants_of(Enum))]