r? @samueltardieu

rustbot has assigned @samueltardieu.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Okay I think ive got it mostly working now, the issue is my new lint interferes with test cases in single_match and I dont know how to tell the system that both warning should so?

Also match_same_arms2.fixed is complaining but I can't find the corresponding test file?

Also match_same_arms2.fixed is complaining but I can't find the corresponding test file?

match_same_arms2.rs?

Adding a new lint that captrures unessary exhaustive patterns for booleans and the built in enums Result and Option

What would be the reason to restrict this lint to Result and Option? What about other enums? Why not handle any enum (which would cover Result and Option) provided that all variants are used and that wildcards are used in place of every variant member?

For example, there is no reason why ControlFlow::Break(_) | ControlFlow::Continue(_) shouldn't be covered.

With regards to the other enums.
Yes this should be applied to any built in enum that we know wont be extended in the future, is there an easier way to identify these?

in the match_same_arms2.fixed file there is a None | Some(_) => 24 which I can't see in the test file

With regards to the other enums. Yes this should be applied to any built in enum that we know wont be extended in the future, is there an easier way to identify these?

All enums not marked non_exhaustive could be concerned, builtin or not.

in the match_same_arms2.fixed file there is a None | Some(_) => 24 which I can't see in the test file

The .fixed file is the result of the application of the auto-fixes (think cargo clippy --fix). You have to look for the original code, before the fix, in the corresponding .rs file.

I'll look into the match_arm stuff later.

The use on applying to any enums conflicts with wildcard_enum_match_arm.
Also could you point me to how I can identify a pattern to be an enum and then get its variants rather than going name by name?

Also could you point me to how I can identify a pattern to be an enum and then get its variants rather than going name by name?

You should find all the information you need from the types section of the Rust compiler development guide. Let us know if something is missing from there. Also, many Clippy lints deal with variants, and you should be able to take inspiration from them.

Rerolling as I'll be AFK for a while.
r? clippy

I'll take a look at the docs for getting other enums, however I mantain that applying this lint to none built-in/standard libarary enums conflicts with wildcard_enum_match_arm.

Nominating this since linting in the area (exhaustive matching) has a bigger design space than we've worked on and would benefit from designing the lint set as a whole rather than just adding more small lints. This is not to say that linting this particular case is a bad idea, just that I believe there are better ways to accomplish this goal.

One thing we could do is have a config for enums which should be explicitly matched and for enums which should not be. There are cases like Option and Result where the variants are well known and won't change, but it's not limited to just those, nor is it limited to just std types. There are cases like any error enum where explicitly matching is usually pointless, but with a few special cases where forcing a full match is useful. At the far end there are enums you want to force explicit matching on every time they're used even if it's only to do something one of the arms like an if let would.