-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
Add lint to tell about let else pattern #8437
Conversation
r? @flip1995 (rust-highfive has picked a reviewer for you, use r? to override) |
dc3602d
to
c33031a
Compare
clippy_lints/src/manual_let_else.rs
Outdated
/// ``` | ||
#[clippy::version = "1.60.0"] | ||
pub MANUAL_LET_ELSE, | ||
restriction, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
restriction, | |
style, |
As long as this only matches let x = if let
, I think it can reasonably be a style lint.
Matching let x = match
would lead to false positives, where someone doesn't want to lose the exhaustive matching or the name of the other variant; that should be a separate allow-by-default restriction lint, with an explicit note that it's intended only for identifying possible locations and some suggestions for where it makes sense to make such a change.
Splitting those two cases into separate lints would allow us to enable the more conservative version by default.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it can reasonably be a style lint.
I would be more careful, as there is no rustfmt support for it yet.
Matching
let x = match
would lead to false positives
Note that I have severely restricted the lint for match
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've been making the assumption that this PR won't get merged until we have full support for let-else. Given that assumption, I think it can be a style lint. I agree that it shouldn't be until then.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@joshtriplett good, we agree then :)
Generally I like the idea of this lint. But as mentioned earlier, it would be good to wait until rust-lang/rust#93628 is merged. So I marked this as |
☔ The latest upstream changes (presumably #8606) made this pull request unmergeable. Please resolve the merge conflicts. |
☔ The latest upstream changes (presumably #8937) made this pull request unmergeable. Please resolve the merge conflicts. |
d545737
to
6692803
Compare
383a44f
to
0e6dc72
Compare
Hmm I still don't understand what you mean by that. But I have refactored the search a little to remove the local mutable variable and use the return types. This has simplified it a little bit I think. One could think about a hybrid that checks the expr's type each time and if it diverges, then early exits. |
7f96771
to
8ac1bae
Compare
@flip1995 I have changed it back to use the visitor based I've also been thinking about the starting lint level of pedantic. Not because I think the lint is bad quality, it's pretty great I think, but because the feature it's endorsing isn't even available on stable yet, just in beta right now, and will be on stable starting November 3rd. I think there is a non zero population of people who use clippy from nightly but still target stable. For them, it would be bad if clippy started linting about this mid of October. Many projects would probably have an explicit msrv set, but I think most still don't. I think this group of people makes up a large group of people who have turned on pedantic lints. Therefore, I think we should do one of the following:
I would prefer the last option, then the second option. What do you think @flip1995 ? Outside of this question, I think all issues should be resolved. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
Good point about people using nightly Clippy but targeting stable. This lint will now only get into nightly 1.67
. And to be absolutely sure about that, I'll wait with merging this until rust-lang/rust#103337 is merged.
So this will only hit nightly when the feature is already stable. No need to take further action here.
@camsteffen I would merge it now with the visitor. I couldn't find a better way to do this when I looked into it. Let me know if you still think this should be changed.
@est31 Great work on the implementation and great code quality (including comments)!
☔ The latest upstream changes (presumably #9541) made this pull request unmergeable. Please resolve the merge conflicts. |
They aren't perfect but better than nothing
We cannot apply the lint for 3-branches like in the added example.
Sometimes type annotations are needed for type inferrence to work, or because of coercions. We don't know this, and we also don't want users to possibly repeat the entire pattern.
Plus, add some tests for the divergence check.
Let's ship it 🚢 Thanks again for all the work! @bors r+ |
☀️ Test successful - checks-action_dev_test, checks-action_remark_test, checks-action_test |
Adds a lint to tell the user if the let_else pattern should be used.
The PR is blocked probably on rustfmt support, as clippy shouldn't suggest features that aren't yet fully supported by all tools.Edit: I guess adding it as a restriction lint for now is the best option, it can be turned into a style lint later.changelog: addition of a new lint to check for manual
let else