-
Notifications
You must be signed in to change notification settings - Fork 1.9k
redundant_pattern_matching added support for more complex patterns
#16254
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
redundant_pattern_matching added support for more complex patterns
#16254
Conversation
|
Lintcheck changes for 40a60e2
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
|
Since this lint is enabled by default I'm going to use the same reasoning for 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() {} |
|
Ok, I see, would we want to turn the support for more complex patterns into a separate allow-by-default-lint? |
|
Ok so I added another lint for these more complex patterns, it uses the same logic as before, but if it finds a complex pattern it just emits a different lint. I put it under |
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 (likeNone):But now it can also catch more complicated nested patterns
The only thing it doesn't support right now is if the redundancy happens because of an or pattern.
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 we were to blindly apply the lint here we would get:
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