Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Add lint to tell about let else pattern #8437
Changes from all commits
f827be9
2e01e6b
c5a7696
5da7a17
173a8e0
9bd70db
a1db931
01e651f
748169d
96ea5b2
dcde480
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
This check must exist in rustc already. The expression inside of the
else
in alet ... else
expression has to be check for divergence as well. So implementing it here in Clippy isn't a good idea. I can imagine that it is just anode_type
on the whole HIR node of theelse
block.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 made this PR some time ago already, so my memory might not be perfect, but I think I remember trying something like that but the type checker did stuff that made it not work in practice, so I ended up with this heuristic which obviously isn't as nice. I think the problem was that the type checker takes the
!
and coerces it to the type of the "then" block, in the step ensuring that "then" and "else" blocks have the same type. So you have to look one level deeper, which this code is doing.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.
As for the check in the
else
expression, that's different code I think from the check that ensures that all match arms have the same type (or if and else blocks).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.
Oh it might be that rust-lang/rust#100288 is doing what we need...
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 you just want to do
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.
Uninhabitedness is not precisely what we need, as currently this fails to compile:
Even though
Un
is uninhabited.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.
Maybe also check if the unadjusted type is an empty enum in addition to uninhabitedness 🤔
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 tried out @camsteffen 's suggestion and the tests
failedit: regress for if let (not for match interestingly). See the last two commits, or alternatively this patch:This lacks the empty enum check, so it is expected that the one false positive is added, but way more importantly, it now starts not firing in quite many instances, something the enum check would not help with. I think this matches my memory. Do you agree that we can go with my version of the code? Unless you have other suggestions.
Btw, running @camsteffen 's suggestion on the dogfood test did turn up one instance that the longer version of the function does not cover, so it was an useful excercise in the end:
The issue here is with the descending behaviour I think, so I think it's fixable.