This does seem like it would catch real problems if done well.
/cc @adonovan

Actually, note that those captures - at least when they are definite bugs - should usually show up in the race detector. It's not clear vet can contribute more than the race detector does without significant false positives.

Although this bug pattern most often manifests with go statements (leading to data races), sequential (non-racy) instances are possible too, such as with defer or the simple example presented in this Issue.

vet already checks for patterns of the form:

for k, v := range seq {
    go/defer func() {
        ... k, v ...
    }()
}

The example presented in this Issue is more challenging to analyze because it requires proving that the function is not called within the loop, or at least failing to prove that it is called within the loop. Once the anonymous function has been stored in a data structure or passed to another function, vet can no longer precisely determine when it might be called.

In other words, I think the current vet check is probably as good as we can do without interprocedural analysis.

It seems to me like we're late to add a new vet check in 1.11, given that the tree is frozen.

Is anyone intending to work on this for 1.12?

Does anyone even know how to solve this problem? I don't.

I'm labelling as NeedsInvestigation, just to clarify that we're not sure that a fix is possible.

See also #20733, which would eliminate this requirement by defining the problem away.

Change https://golang.org/cl/164119 mentions this issue: cmd/link: do not close over the loop variable in testDWARF

adds (*errgroup.Group).Go alongside defer and go as unsafe uses of function literals at the end of a loop

Is now supported in loopclosure.

improper t.Run and t.Parallel usage

This is something we have been considering adding support for in vet. This would most likely need to follow roughly the same pattern as loopclosure does. Someone from the community could contribute this.

We are currently in 1.18 code freeze, but this may be able to make it into 1.19.

Fwiw the specific case that led me to this issue was that my loop contained an if statement as the last statement, and my goroutine(s) we're the last statements in each if branch.

@glenjamin Can you provide or point to a [possibly simplified] example? (This checker is quite sensitive to syntax to keep false positives down.)

@timothy-king sure - The body of the loop here is almost identical to my real code (I deleted a couple of lines of logging from the top of the loop body)

This compiles and passes vet, but is incorrect.

package main

import (
	"context"
	"sync"

	"golang.org/x/sync/errgroup"
)

func main() {
	var nodes []interface{}

	ctx := context.Background()
	critical, ctx := errgroup.WithContext(ctx)
	others := sync.WaitGroup{}

	for i, node := range nodes {
		// i, node := i, node
		if IsCritical(node) {
			critical.Go(func() error {
				return run(ctx, i, node)
			})
		} else {
			others.Add(1)
			go func() {
				// We don't care about errors in non-critical nodes
				_ = run(ctx, i, node)
				others.Done()
			}()
		}
	}
}

func IsCritical(node interface{}) bool {
	return false
}

func run(ctx context.Context, i int, node interface{}) error {
	return nil
}

@glenjamin That specific example is supportable in loopclosure. This would require extending the logic of looking for the "last" statement within the RangeStmt to include statements that unconditionally lead to the end of the RangeStmt if they are executed. If branches fit into this. Both branches do not need to match. Just one.

IMO the justification is fairly solid. We can rework the above example into something I expect loopclosure to warn on:

	for i, node := range nodes {
		// i, node := i, node
		if IsCritical(node) {
			critical.Go(func() error {
				return run(ctx, i, node)
			})
			continue // minor refactor
		}
		others.Add(1)
		go func() { // now the last statement
			// We don't care about errors in non-critical nodes
			_ = run(ctx, i, node)
			others.Done()
		}()
	}

Again we welcome community contributions on this (and we are currently in the 1.18 freeze).

Actually, note that those captures - at least when they are definite bugs - should usually show up in the race detector.

Unfortunately @rsc , they don't, in a typical buggy table test case:

func TestParallel(t *testing.T) {
	tests := []struct {name string}{{name: "case1"}, {name: "case2"}}
	for _, tt := range tests {
		t.Run(tt.name, func(t *testing.T) {
			t.Parallel()
			fmt.Println(tt.name)
		})
	}
}

This buggy output and no warning from race detector:

$ go test -race -v .
=== RUN   TestParallel
=== RUN   TestParallel/case1
=== PAUSE TestParallel/case1
=== RUN   TestParallel/case2
=== PAUSE TestParallel/case2
=== CONT  TestParallel/case2
case2
=== CONT  TestParallel/case1
case2
--- PASS: TestParallel (0.00s)
    --- PASS: TestParallel/case2 (0.00s)
    --- PASS: TestParallel/case1 (0.00s)
PASS

@porridge they would, if you run subtests in parallel.

@invidian do they for you?
Adding -test.parallel=3 to that command line does not help on my end.

Ah, I misread and haven't noticed t.Parallel(). Race detector does not trigger indeed. Sorry for the noise.

We have a version of the loopclosure check within Monzo that uses a bunch of heuristics to avoid false positives and has good coverage of most bugs.

@danielchatfield any updates on making this available to the community?

@invidian, the t.Parallel issue in general is #35670. (It masks other kinds of races too, not just races on loop variables.)

See #56010 for a different approach.

Change https://go.dev/cl/452155 mentions this issue: go/analysis/passes/loopclosure: recursively check last statements in statements like if, switch, and for

Given the interest in possibly redefining for loop variable semantics in #56010, I thought it might be useful to try to complete the sketch for extending the loopclosure checker that @adonovan suggested above a few years ago in #16520 (comment).

Rather than the checker examining the last statement in a loop body, the "last" statement examined by the checker becomes defined recursively (e.g., if the last statement in the loop body is a switch statement, then the analyzer examines the last statements in each of the switch cases).

I sent CL https://go.dev/cl/452155, which does that, and now properly flags the example above from @dmowcomber.

One question @timothy-king raised in the Gerrit discussion is whether or not that change would need to go through the proposal process. Are there any quick opinions on that?

I'd be happy to open a proposal if that's the recommendation.

(I will likely open a separate proposal for some possible follow-on approaches, but my more immediate question is if CL 452155 should have a proposal).

Hi @glenjamin, FYI, https://go.dev/cl/452155 also seems to properly flag your example from above as well, and stops complaining if you uncomment the i, node := i, node line:

func main() {
	var nodes []interface{}

	ctx := context.Background()
	critical, ctx := errgroup.WithContext(ctx)
	others := sync.WaitGroup{}

	for i, node := range nodes {
		// i, node := i, node
		if IsCritical(node) {
			critical.Go(func() error {
				return run(ctx, i, node) // vet now warns i and node captured by func literal
			})
		} else {
			others.Add(1)
			go func() {
				// We don't care about errors in non-critical nodes
				_ = run(ctx, i, node) // vet now warns i and node captured by func literal
				others.Done()
			}()
		}
	}
}

func IsCritical(node interface{}) bool                       { return false }
func run(ctx context.Context, i int, node interface{}) error { return nil }

Given that this is improving the precision of an existing vet check, without introducing any new false positives, I don't believe it needs to go through the proposal process.

Change https://go.dev/cl/455195 mentions this issue: go/analysis/passes/loopclosure: allow certain well-understood statements to trail problematic go and defer statements

Is this no longer relevant with go1.22 / should be closed? @adonovan

• spec: less error-prone loop variable scoping #60078
• https://go.dev/blog/loopvar-preview
• https://go.dev/blog/go1.22

The long-standing “for” loop gotcha with accidental sharing of loop variables between iterations is now resolved.

Yep. It is fine to close this with the 1.22 lifetime rules.