-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
option_if_let_else suggestion does not compile #6137
Comments
Despite this bug report, I am planning on disabling this lint since in every case clippy offered the correction, I found the explicit if let ... else more readable than the combinator soup I never remember the argument order for. A particular suggestion I did not like was replacing an if let .. else that was part of an if else chain. diff --git a/spinoso-env/src/env/memory.rs b/spinoso-env/src/env/memory.rs
index 00b94517f2..af1ff8cff0 100644
--- a/spinoso-env/src/env/memory.rs
+++ b/spinoso-env/src/env/memory.rs
@@ -98,10 +98,10 @@ impl Memory {
// MRI accepts names containing '=' on get and should always return
// `nil` since these names are invalid at the OS level.
Ok(None)
- } else if let Some(value) = self.store.get(name) {
- Ok(Some(Cow::Borrowed(value)))
} else {
- Ok(None)
+ self.store
+ .get(name)
+ .map_or(Ok(None), |value| Ok(Some(Cow::Borrowed(value))))
}
} In this case, if this method were const, the suggestion would make the resulting code not const. |
Also address new clippy lints and updates. This commit disables some lints due to rust-lang/rust-clippy#6137 and rust-lang/rust-clippy#6141.
One thing you could do to fix the compiler warning would be to use
That's totally fine, pedantic lints are meant to be really opinionated and to be |
Downgrade option_if_let_else to nursery I believe that this lint's loose understanding of ownership (#5822, #6737) makes it unsuitable to be enabled by default in its current state, even as a pedantic lint. Additionally the lint has known problems with type inference (#6137), though I may be willing to consider this a non-blocker in isolation if it weren't for the ownership false positives. A fourth false positive involving const fn: #7567. But on top of these, for me the biggest issue is I basically fully agree with #6137 (comment). In my experience this lint universally makes code worse even when the resulting code does compile. --- changelog: remove [`option_if_let_else`] from default set of enabled lints
Fix `option_if_let_else` fixes: #5822 fixes: #6737 fixes: #7567 The inference from #6137 still exists so I'm not sure if this should be moved from the nursery. Before doing that though I'd almost want to see this split into two lints. One suggesting `map_or` and the other suggesting `map_or_else`. `map_or_else` tends to have longer expressions for both branches so it doesn't end up much shorter than a match expression in practice. It also seems most people find it harder to read. `map_or` at least has the terseness benefit of being on one line most of the time, especially when the `None` branch is just a literal or path expression. changelog: `break` and `continue` statments local to the would-be closure are allowed in `option_if_let_else` changelog: don't lint in const contexts in `option_if_let_else` changelog: don't lint when yield expressions are used in `option_if_let_else` changelog: don't lint when the captures made by the would-be closure conflict with the other branch in `option_if_let_else` changelog: don't lint when a field of a local is used when the type could be pontentially moved from in `option_if_let_else` changelog: in some cases, don't lint when scrutinee expression conflicts with the captures of the would-be closure in `option_if_let_else`
I tried this code:
Clippy made this suggestion:
Applying the fix results in code that does not compile:
Meta
cargo clippy -V
: clippy 0.0.212 (18bf6b4f0 2020-10-07)rustc -Vv
:The text was updated successfully, but these errors were encountered: