-
Notifications
You must be signed in to change notification settings - Fork 4.7k
Ensure all locks (.lock(), .read(), .write(), etc.) aren't held over if let
statements
#24836
Comments
Once this clippy lint makes it into nightly, I think we should start applying it in CI: rust-lang/rust#93883 |
The latest nightly rust (rust version 1.62.0-nightly (cb1219871 2022-05-08)) now has the lint I linked above and it can be run with |
Clippy found these two:
(PR #25094 to fix the above warning.)
|
Hmm can you try running before the recent patches on master? I would have expected a few more |
if let
statementsif let
statements
I ran it again from commit Was there a different commit you wanted me to run against? It may be worthwhile to double check my results by running it also, so there's another datapoint. Maybe this new lint doesn't pick up everything yet? |
Hmm I'm thinking it's not working quite right yet then. Would be interesting to dig into why. (cc @PrestonFrom if you want to join in) |
@jstarry Thanks for letting me know. I think I found the issue -- working on a fix but not sure on the timeline. |
Happy to hear that, thanks for taking a look. No rush from us, we really appreciate your work so far on that lint! |
Problem
See this for context:
rust-lang/rust#93883
https://www.reddit.com/r/rust/comments/ldic3m/confusing_point_regarding_scope_and_dropped_value/
I was recently running into some type of deadlock issue in block_subscribe which i narrowed down to unexpectedly holding locks across if let. Something like:
Proposed Solution
if let
statements. @jstarry and @brooksprumo has started to fix this in Do not hold lock unnecessarily when hashing #24815 and Avoid holding lock guards in match expressions #24805.The text was updated successfully, but these errors were encountered: