Skip to content

Actually hold the total_consistency_lock instead of take-and-drop #731

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

Merged
merged 1 commit into from
Oct 2, 2020

Conversation

TheBlueMatt
Copy link
Collaborator

It was noticed (via clippy) by @casey that we were taking and then
immediately dropping the total_consistency_lock because let _ =
doesn't actually bind the response to anything. This appears to be
a consequence of wanting if let Some(_) = to not hold a ref to
the contained value at all, but is relatively surprising to me.

Sadly, this case is super hard to test and, worse, clippy isn't even supported without rustup, making it hard to integrate clippy into (at least my) workflow.

It was noticed (via clippy) by @casey that we were taking and then
immediately dropping the total_consistency_lock because `let _ =`
doesn't actually bind the response to anything. This appears to be
a consequence of wanting `if let Some(_) =` to not hold a ref to
the contained value at all, but is relatively surprising to me.
@TheBlueMatt TheBlueMatt added this to the 0.0.12 milestone Oct 2, 2020
@jkczyz jkczyz self-requested a review October 2, 2020 18:27
@valentinewallace
Copy link
Contributor

Wow that's insidious. Seems like a footgun.

@TheBlueMatt TheBlueMatt merged commit 937d1d8 into lightningdevkit:main Oct 2, 2020
@ariard
Copy link

ariard commented Oct 2, 2020

We didn't hold oh ? Post-merge Code Review ACK ddebf36

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants