/cc @josharian

Change https://golang.org/cl/56671 mentions this issue: [dev.boringcrypto] crypto/ecdsa: use unsafe.Pointer instead of atomic.Value

Change https://golang.org/cl/57941 mentions this issue: [dev.boringcrypto.go1.8] crypto/ecdsa: use unsafe.Pointer instead of atomic.Value

A different solution might be to ignore the noCopy property on initialization in a pure literal expression. Before assigning the result of a literal to a specific value there are no concurrency issues to worry about. So the false positive is actually a vet bug related to literals and it might make sense to track and treat it as such after closing this issue.

Note: Pure literal expression means constructed by either trivial assignments of other literals or constants or by calling pure functions (as in https://en.wikipedia.org/wiki/Pure_function).

I wasn't able to reproduce the false positive in the report:

package main

import (
	"sync/atomic"
)

type Y struct {
	v atomic.Value
}

type X struct {
	Y Y
}

func main() {
	var x X
	// None of these trigger the vet nocopy check:
	x = X{
		Y: Y{},
	}
	x.Y = Y{}

	// This does, though:
	y := x.Y
}

Also at https://play.golang.org/p/MfsefrZzGB.

Maybe @rsc was just running into a vet bug of some kind. (Perhaps even one that has been fixed?) I'm thinking of #16227 or #13675.

However, I agree that atomic.Value shouldn't have noCopy because its stated copying semantics are more complicated than "do not copy an atomic.Value". I guess this program should be okay(?) but vet warns about it:

package main

import (
	"fmt"
	"sync/atomic"
)

func main() {
	var v0 atomic.Value
	v1 := v0 // assignment copies lock value to v1: sync/atomic.Value contains sync/atomic.noCopy
	v0.Store(3)
	v1.Store(4)
	fmt.Println(v0.Load())
	fmt.Println(v1.Load())
}

Change https://golang.org/cl/80836 mentions this issue: sync/atomic: remove noCopy from Value