You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Create testvet.go and testvet_linux.go on same directory and run go vet *.go or go tool vet *.go
File testvet.go:
// +build freebsd netbsd openbsd dragonfly darwin
package testvet
import "sync"
type ScanDir struct {
dir string
services sync.Map
}
func main() {
s := new(ScanDir)
s.services.Delete("foo")
}
File testvet_linux.go:
// +build linux
package testvet
type ScanDir struct {
dir string
services map[string]string
}
func main() {
s := new(ScanDir)
delete(s.services, "foo")
}
What did you expect to see?
nothing like in go versions <=1.9
What did you see instead?
With go vet *.go:
testvet_linux.go:12: call of delete copies lock value: sync.Map contains sync.Mutex
exit status 1
With go tool vet *.go:
testvet_linux.go:12: call of delete copies lock value: sync.Map contains sync.Mutex
The text was updated successfully, but these errors were encountered:
ianlancetaylor
changed the title
go vet *.go / go tool vet *.go ignore Build Constraints when using sync.Map
cmd/vet: go vet *.go / go tool vet *.go ignore Build Constraints when using sync.Map
Nov 4, 2017
Nothing has changed with regard to how cmd/vet handles build constraints when invoked with a list of files. In all cases it checks all the files. You can see this easily enough by adding something that triggers a warning, such as fmt.Printf("%s"), to both files. If you run go vet *.go, you will see both warnings.
What has changed is how cmd/vet handles duplicate definitions. On tip, the future 1.10, cmd/vet actually emits errors:
./a_linux.go:7:6: ScanDir redeclared in this block
previous declaration at ./a.go:8:6
./a_linux.go:12:6: main redeclared in this block
previous declaration at ./a.go:13:6
In all cases, go vet (without the *.go) honors build constraints as expected. I recommend using that.
I'm inlined to simply close this issue with the recommendation to use plain go vet. Is there a reason I shouldn't do that? We aren't going to change cmd/vet to honor build constraints when files are explicitly listed on the command line; it has never done that and I don't see any reason to start.
Hi @ianlancetaylor many thanks for the explanation, was confusing me since before 1.9 there was no error or either warning, but also before 1.9 there was not sync.Map therefore I though could be a bug.
Please answer these questions before submitting your issue. Thanks!
What version of Go are you using (
go version
)?go version go1.9.2 darwin/amd64
Does this issue reproduce with the latest release?
yes
What operating system and processor architecture are you using (
go env
)?What did you do?
Create
testvet.go
andtestvet_linux.go
on same directory and rungo vet *.go
orgo tool vet *.go
File
testvet.go
:File
testvet_linux.go
:What did you expect to see?
nothing like in go versions <=1.9
What did you see instead?
With
go vet *.go
:With
go tool vet *.go
:The text was updated successfully, but these errors were encountered: