-
Notifications
You must be signed in to change notification settings - Fork 1.7k
extend obfuscated_if_else
to support {then(), then_some()}.unwrap_or_else()
#14165
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
extend obfuscated_if_else
to support {then(), then_some()}.unwrap_or_else()
#14165
Conversation
4c00a09
to
9642c7d
Compare
Rebased. |
9642c7d
to
264403a
Compare
Rebased. |
@blyxyas Should I reassign? (I pinged you because it's been over 2 weeks) |
Sorry, this issue in particular has slipped under the radar on my org system. I will get a review today (I will start a review right now) |
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.
Looking good! Just some comments (one logical observation, and one nit).
66d3a9c
to
a8a6598
Compare
…`then_some().unwrap_or_else()`
a8a6598
to
6c6ffd2
Compare
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, great change, thanks! ❤️
With Rust 1.87 beta, clippy started warning about some new instances of the obfuscated-if-else lint. This appears to have been introduced in rust-lang/rust-clippy#14165, which was a change that made sense to me. But because we deny the warn-by-default group, clippy::all, CI began failing, which is fine. This commit resolves the two instances of this lint in the codebase by using inline if-else's. Signed-off-by: Kristofer Rye <[email protected]>
These method chains can be expressed concisely with
if
/else
.changelog: [
obfuscated_if_else
]: supportthen().unwrap_or_else()
andthen_some().unwrap_or_else()