Related #8732. Generally, vet can only reliably prove an issue for the last statement in the loop. Using captured loop variables in earlier statements isn't provably incorrect. The closure could be executed before the end of the loop iteration. For example:

for i := range s {
  fn := func() { println(i) }
  useCallback(fn) // useCallback returns only after fn has been called
}

Similarly, spawned goroutines can be waited on.

Good point, but we can do better for explicit go and defer statements.

Can you elaborate on which additional cases we could catch with regard to go? Keep in mind that goroutines that close over loop variables aren't categorically wrong. For example:

for i := range s {
	wg := &sync.WaitGroup{}
	wg.Add(2)
	go func() {
		work1(i)
		wg.Done()
	}()
	go func() {
		work2(i)
		wg.Done()
	}()
	wg.Wait()
}

I filed this for https://groups.google.com/d/msg/golang-nuts/M9Hq76csSaU/nVrpNOXyBwAJ which has examples of problems that we could catch.

Thanks for filing this, Ian.

Here's the real-world code that caused problems at my company. Once the root cause was traced to this bug, engineers responsible for this code were surprised (and slightly alarmed) that vet didn't warn them first.

I've redacted or altered a few of the object names, but the idea should be clear. The code handles a batch of requests, then gathers errors for later.

func (r *redactedStruct) handleBatch(ctx context.Context, batch *redactedpkg.Batch) error {
	var chans []chan error
	for _, request := range batch.Requests {
		c := make(chan error)
		go func(c chan error) {
			c <- r.handle(ctx, request)
		}(c)
		chans = append(chans, c)
	}

	var err error
	for _, c := range chans {
		err = combineErrors(err, <-c)
	}
	return err
}

Thanks for the example. So the question is whether vet can be smart enough to see that chans = append(chans, c) will not wait for a goroutine to complete.

Duplicate of #16520 I believe.