Skip to content

Conversation

@mendelsshop
Copy link

@mendelsshop mendelsshop commented Dec 18, 2025

changelog: [redundant_pattern_matching]: Improved this lint by allowing to handle more complex patterns beyond just _

Before, the lint would only activate when the pattern was an _ or if the constructor was a unit constructor (like None):

while let Some(_) = Some(42) {}

But now it can also catch more complicated nested patterns

struct Foo { x: i32 }
enum E {
     Unit
}
if let Some((Foo { x: _}, _, E::Unit)) = None {}

The only thing it doesn't support right now is if the redundancy happens because of an or pattern.

if let Some(Some(Some(_) | None)) = None {}

Edit:
I also made that the only slice patterns that are checked are [..] and [] because in all the other cases we are constraining the size of what we are matching to be bigger:

if let Some([_, _, ..]) = Some(&[1] as &[i32]) {}

If we were to blindly apply the lint here we would get:

if Some(&[1] as &[i32]).is_some() {}

And the condition would (incorrectly) be true even if the slice was the less than length two.
For [T: N] we could make it work and only activate the lint if for the pattern [x0, ... xn] N > n.

fixes #16235

@rustbot rustbot added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties label Dec 18, 2025
@rustbot
Copy link
Collaborator

rustbot commented Dec 18, 2025

r? @Jarcho

rustbot has assigned @Jarcho.
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

@github-actions
Copy link

github-actions bot commented Dec 18, 2025

Lintcheck changes for f0076b7

Lint Added Removed Changed
clippy::redundant_pattern_matching 11 0 1

This comment will be updated if you push new changes

… are just have `..`

before (in the last commit) any "sized" slice pattern could trigger the redundant_pattern_matching.
This is a problem the size of the slice says something about the value we are matching against
@Jarcho
Copy link
Contributor

Jarcho commented Dec 18, 2025

Since this lint is enabled by default I'm going to use the same reasoning for let_unit_value and say we can't lint on this. People use the additional part of the pattern as an assertion about the types involved.

This also doesn't take into account if the pattern is needed for type inference. e.g.

fn foo<T>() -> Result<T, ()> {panic!()}
if let Ok(()) = foo() {}

@mendelsshop
Copy link
Author

Ok, I see, would we want to turn the support for more complex patterns into a separate allow-by-default-lint?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

S-waiting-on-review Status: Awaiting review from the assignee but also interested parties

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Various infalliable patterns in clippy::redundant_pattern_matching

3 participants