go: cmd/vet: go vet -vettool=$(which shadow) errors in go1.13 only (flag provided but not defined: -unsafeptr)
What version of Go are you using (go version
)?
$ go version go version go1.13 linux/amd64
Does this issue reproduce with the latest release?
Yes
Does this issue reproduce with the previous release?
No
What operating system and processor architecture are you using (go env
)?
go env
Output
$ go env GO111MODULE="" GOARCH="amd64" GOBIN="/home/leighmcculloch/local/bin" GOCACHE="/home/leighmcculloch/.cache/go-build" GOENV="/home/leighmcculloch/.config/go/env" GOEXE="" GOFLAGS="" GOHOSTARCH="amd64" GOHOSTOS="linux" GONOPROXY="" GONOSUMDB="" GOOS="linux" GOPATH="/home/leighmcculloch/go" GOPRIVATE="" GOPROXY="https://proxy.golang.org,direct" GOROOT="/home/leighmcculloch/local/bin/go/1.13" GOSUMDB="sum.golang.org" GOTMPDIR="" GOTOOLDIR="/home/leighmcculloch/local/bin/go/1.13/pkg/tool/linux_amd64" GCCGO="gccgo" AR="ar" CC="gcc" CXX="g++" CGO_ENABLED="1" GOMOD="/home/leighmcculloch/devel/stellar-go/go.mod" CGO_CFLAGS="-g -O2" CGO_CPPFLAGS="" CGO_CXXFLAGS="-g -O2" CGO_FFLAGS="-g -O2" CGO_LDFLAGS="-g -O2" PKG_CONFIG="pkg-config" GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build252896639=/tmp/go-build -gno-record-gcc-switches"
What did you do?
$ mkdir test
$ cd test
$ go mod init test
$ cat > main.go <<-EOF
package main
import "fmt"
func main() {
v := "bye"
for {
v := "hello"
fmt.Println(v)
break
}
fmt.Println(v)
}
EOF
$ go get -u golang.org/x/tools/go/analysis/passes/shadow/cmd/shadow
$ go vet -vettool=$(which shadow)
What did you expect to see?
I expected to see the output indicating the shadow variable:
$ go vet -vettool=$(which shadow)
# test
./main.go:8:3: declaration of "v" shadows declaration at line 6
What did you see instead?
The output was huge, 1541
lines of output. It was repeatedly dumping out an error flag provided but not defined: -unsafeptr
once for some number of standard library packages along with the usage documentation for the shadow command. At the very end was the output I expected.
$ go vet -vettool=$(which shadow)
# internal/cpu
flag provided but not defined: -unsafeptr
shadow: check for possible unintended shadowing of variables
Usage: shadow [-flag] [package]
This analyzer check for shadowed variables.
...
# test
./main.go:8:3: declaration of "v" shadows declaration at line 6
To condense the output down a bit we can see the packages it is displaying the error about:
$ go vet -vettool=$(which shadow) 2>&1 | grep '^#'
# internal/cpu
# runtime/internal/sys
# internal/bytealg
# runtime/internal/math
# unicode/utf8
# internal/race
# sync/atomic
# unicode
# math/bits
# internal/testlog
# runtime/internal/atomic
# math
# runtime
# internal/reflectlite
# sync
# sort
# errors
# io
# internal/oserror
# strconv
# syscall
# reflect
# internal/syscall/unix
# time
# internal/fmtsort
# internal/poll
# os
# fmt
# test
Does this issue reproduce with the previous release? (details)
No. This doesn’t happen with Go 1.12.9. If I run the above commands with that version of Go, it behaves as expected and outputs the shadow errors. Example:
$ go1.12.9 vet -vettool=$(which shadow)
# test
./main.go:8:3: declaration of "v" shadows declaration at line 6
About this issue
- Original URL
- State: closed
- Created 5 years ago
- Reactions: 1
- Comments: 15 (10 by maintainers)
Commits related to this issue
- all: drop support for go1.11, add support for go1.13 (#1700) Add testing and support for Go 1.13 and discontinue support for Go 1.11. To maintain consistency with supported and released versions o... — committed to stellar/go by leighmcculloch 5 years ago
- all: run go vet shadow for all go versions (#1778) Run the go vet tool `shadow` for all Go versions, specifically making it possible to run it with Go 1.13. We should have consistent checks and te... — committed to stellar/go by leighmcculloch 5 years ago
- fix https://github.com/golang/go/issues/34053#issuecomment-532386030 — committed to cmaster11/overseer by cmaster11 5 years ago
- [release-branch.go1.13] cmd/go/internal/work: fix error while passing custom vet tool For GOROOT packages, we were adding -unsafeptr=false to prevent unsafe.Pointer checks. But the flag also got pass... — committed to golang/go by agnivade 5 years ago
- all: remove go vet shadow hack (#1860) Remove the work around that was added in 828c132a75607ec7747c1ef9d5c44cfd65432003 that built our own custom `shadow` binary that was able to handle the presence... — committed to stellar/go by leighmcculloch 5 years ago
- Bump minimum Go version required Requires Go 1.13.3 to avoid build error (actually, fails on `go vet` using `shadow`) due to https://github.com/golang/go/issues/34053 — committed to mattermost/mmctl by wiggin77 4 years ago
- Bump minimum Go version required (#98) Requires Go 1.13.3 to avoid build error (actually, fails on `go vet` using `shadow`) due to https://github.com/golang/go/issues/34053 — committed to mattermost/mmctl by wiggin77 4 years ago
Change https://golang.org/cl/200957 mentions this issue:
cmd/go/internal/work: fix error while passing custom vet tool
Could we instead not pass this flag down to custom tools? It seems unnecessary to require all vettool programs to support this flag.
By the time I found this issue, I already spent too much time trying to figure out what was wrong in my codebase. Now I am bothered enough to fix this.
There seems to be a separate
VetTool
flag which indicates a presence of an alternate binary.Adding this to the if condition should do it. Will send a CL.
If it helps anyone, I used the following workaround (building on @matloob’s suggestion):
Save this in a file called, say,
customvettool/customvettool.go
. Rungo install ./customvettool
to install the binary, and then you can invoke asgo vet -vettool=$(which customvettool)
.Is there any workaround? etcd https://github.com/etcd-io/etcd/pull/11110 is experiencing the same issue…
Will this fix get back ported into 1.13?