-
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
Suggest Option::map_or
(_else) for if let Some { y } else { x }
#5301
Conversation
For your first point, there's a pretty simple solution: If the block has statements (besides the returning expression), then you should suggest For your second point. The For the other two: This new lint should never trigger, if there is a |
☔ The latest upstream changes (presumably #5319) made this pull request unmergeable. Please resolve the merge conflicts. |
☔ The latest upstream changes (presumably #5294) made this pull request unmergeable. Please resolve the merge conflicts. |
☔ The latest upstream changes (presumably #5438) made this pull request unmergeable. Please resolve the merge conflicts. |
I pulled the changes which happened in the master branch while I was gone (sorry for the delay, I had things to deal with involving COVID-19, but everything's fine now), and now, when I try to build, it complains: error[E0463]: can't find crate for I've tried everything I can think of to make it appear, but nothing seems to make it work. If it matters, here's the output of running
Is there anything that I need to do to make that crate appear? |
ff0e564
to
038ab65
Compare
Failed tests are |
Option::map_or
(_else) for if let Some { y } else { x }
Option::map_or
(_else) for if let Some { y } else { x }
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.
Sorry for taking so long for the review. I don't have an excuse, just wasn't really motivated to review PRs recently.
To get the latest rustc toolchain, you should run |
After undoing the change to |
d074cdd
to
f958879
Compare
☔ The latest upstream changes (presumably #5423) made this pull request unmergeable. Please resolve the merge conflicts. |
f958879
to
ff4da34
Compare
@bors r+ Thanks! |
📌 Commit ff4da34 has been approved by |
Suggest `Option::map_or`(_else) for `if let Some { y } else { x }` Fixes #5203 There are two issues with this code that I have noticed: - Use of `Option::map_or` causes it to always evaluate the code in the else block. If that block is computationally expensive or if it updates some state (such as getting the next value from an iterator), then this change would cause the code to behave differently. In either of those circumstances, it should suggest Option::map_or_else, which takes both cases as a closure and runs one. However, I don't know how to check if the expression would change some state, so I left the lint's applicability as MaybeIncorrect. - There are lints which can trigger on specific sub-cases of this lint (`if_let_some_result`, `question_mark`, and `while_let_loop`) and suggest different changes (usually better ones because they're more specific). Is this acceptable for clippy to give multiple suggestions, or should I have the code check if those other lints trigger and then not trigger this lint if they do?
💔 Test failed - checks-action_test |
There are a lot of findings in the Clippy codebase itself. You should be able to use $ cargo +master install --path . --force # Install Clippy
$ cp ~/.cargo/bin/*clippy* ~/.rustup/toolchains/master/bin # Make Clippy available in the master toolchain
$ export LD_LIBRARY_PATH=$(rustc +master --print sysroot)/lib # Set library path
$ cd clippy_lints
$ cargo +master clippy --fix -Zunstable-options # Fix findings with the previously installed clippy
$ cd -
$ cargo dev fmt # reformat codebase |
☔ The latest upstream changes (presumably #5751) made this pull request unmergeable. Please resolve the merge conflicts. |
890e4b6
to
d9fe3b0
Compare
Thanks for rebasing! There's again some fallout of the rebase ( |
☔ The latest upstream changes (presumably #5763) made this pull request unmergeable. Please resolve the merge conflicts. |
72e88af
to
1c32263
Compare
020cc8c
to
c8f700e
Compare
@flip1995 Sorry for the delay. I had to force-push without it quite working yet because something broke on my machine that causes it to randomly fail a test in the middle, so using the automatic Travis testing was the only way I could actually test it. But it passes all the tests now, so it should finally be good to merge. |
@bors r+ p=10 Thanks! |
📌 Commit c8f700e has been approved by |
☀️ Test successful - checks-action_dev_test, checks-action_remark_test, checks-action_test |
FYI, issues arising from this lint:
|
Fixes #5203
There are two issues with this code that I have noticed:
Use of
Option::map_or
causes it to always evaluate the code in the else block. If that block is computationally expensive or if it updates some state (such as getting the next value from an iterator), then this change would cause the code to behave differently. In either of those circumstances, it should suggest Option::map_or_else, which takes both cases as a closure and runs one. However, I don't know how to check if the expression would change some state, so I left the lint's applicability as MaybeIncorrect.There are lints which can trigger on specific sub-cases of this lint (
if_let_some_result
,question_mark
, andwhile_let_loop
) and suggest different changes (usually better ones because they're more specific). Is this acceptable for clippy to give multiple suggestions, or should I have the code check if those other lints trigger and then not trigger this lint if they do?changelog: Add lint [
option_if_let_else
]