-
Notifications
You must be signed in to change notification settings - Fork 3.9k
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
loopvarcapture: do not flag defer
within local closure
#83418
loopvarcapture: do not flag defer
within local closure
#83418
Conversation
Previously, handling of `defer` statements in the `loopvarcapture` linter was naive: whenever a `defer` statement in the body of a loop referenced a loop variable, the linter would flag it as an invalid reference. However, that can be overly restrictive, as a relatively common idiom is to create literal functions and immediately call them so as to take advantage of `defer` semantics, as in the example below: ```go for _, n := range numbers { // ... func() { // ... defer func() { doSomewithing(n) }() // always safe // ... }() } ``` The above reference is valid because it is guaranteed to be called with the correct value for the loop variable. A similar scenario occurs when a closure is assigned to a local variable for use within the loop: ```go for _, n := range numbers { // ... helper := func() { // ... defer func() { doSomething(n) }() // ... } // ... helper() // always safe } ``` In the snippet above, calling the `helper` function is also always safe because the `defer` statement is scoped to the closure containing it. However, it is still *not* safe to call the helper function within a Go routine. This commit updates the `loopvarcapture` linter to recognize when a `defer` statement is safe because it is contained in a local closure. The two cases illustrated above will no longer be flagged, allowing for that idiom to be used freely. Release note: None.
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.
I can confirm that this fixes the linter issue with #79663. Thanks!
Reviewable status:
complete! 0 of 0 LGTMs obtained (waiting on @srosenberg)
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.
friendly ping! can we merge this so I can unblock my PR? the test case looks straightforward to me.
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.
Reviewed 2 of 2 files at r1, all commit messages.
Reviewable status:complete! 1 of 0 LGTMs obtained (waiting on @renatolabs)
bors r=srosenberg,dhartunian Thanks! |
Build succeeded: |
Previously, handling of
defer
statements in theloopvarcapture
linter was naive: whenever a
defer
statement in the body of a loopreferenced a loop variable, the linter would flag it as an invalid
reference. However, that can be overly restrictive, as a relatively
common idiom is to create literal functions and immediately call them
so as to take advantage of
defer
semantics, as in the example below:The above reference is valid because it is guaranteed to be called
with the correct value for the loop variable.
A similar scenario occurs when a closure is assigned to a local
variable for use within the loop:
In the snippet above, calling the
helper
function is also alwayssafe because the
defer
statement is scoped to the closure containingit. However, it is still not safe to call the helper function within
a Go routine.
This commit updates the
loopvarcapture
linter to recognize when adefer
statement is safe because it is contained in a localclosure. The two cases illustrated above will no longer be flagged,
allowing for that idiom to be used freely.
Release note: None.