go vet std is reporting problems and exiting with a non-zero code on latest master (see #37030):
src $ go version
go version devel +a864cc7560 Wed Feb 5 14:32:50 2020 +0000 darwin/amd64
src $ go vet std
sync/atomic/value.go:59:44: possible misuse of unsafe.Pointer
runtime/internal/atomic/atomic_test.go:94:7: possible misuse of unsafe.Pointer
strings/builder.go:30:9: possible misuse of unsafe.Pointer
runtime/alg.go:56:22: possible misuse of unsafe.Pointer
runtime/atomic_pointer.go:63:9: possible misuse of unsafe.Pointer
runtime/cgocall.go:200:13: possible misuse of unsafe.Pointer
runtime/cgocall.go:282:16: possible misuse of unsafe.Pointer
runtime/cgocall.go:287:16: possible misuse of unsafe.Pointer
src $ echo $?
Need to investigate why the builders didn't catch this. We used to have a misc-vet-vetall builder but that has changed in #31916. /cc @rsc@cagedmantis@toothrot
The text was updated successfully, but these errors were encountered:
This turned out to be an undetected regression in the behavior of go vet itself.
When we turned down misc-vet-vetall, we made the implicitvet checks for standard-library packages during go test more aggressive, so that they run all vet checks except for unsafeptr instead of the only the high-confidence checks.
And that's why it wasn't caught: we were testing a (slightly) different property from the one we actually wanted to hold. The testing verified that “all vet checks except for unsafeptr pass for packages in the standard library”, but the property we want is “go vet reports no failures for packages in the standard library”. That property only holds if go vet runs exactly “all vet checks except for unsafeptr”.
We didn't have a regression test for that last part, so when it regressed we also didn't detect the regression in the desired property that it implies.