Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cmd/vet: `GO111MODULE=off go test -count=1 cmd/vet` fails #32107

Open
cuonglm opened this issue May 17, 2019 · 20 comments

Comments

Projects
None yet
5 participants
@cuonglm
Copy link
Contributor

commented May 17, 2019

What version of Go are you using (go version)?

$ go version
go version devel +9be2d46422 Fri May 17 06:01:17 2019 +0000 linux/amd64

Does this issue reproduce with the latest release?

No

What operating system and processor architecture are you using (go env)?

go env Output
$ go env
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/cuonglm/.cache/go-build"
GOENV="/home/cuonglm/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/cuonglm/go"
GOPROXY="direct"
GOROOT="/home/cuonglm/sources/go"
GOSUMDB="off"
GOTMPDIR=""
GOTOOLDIR="/home/cuonglm/sources/go/pkg/tool/linux_amd64"
GCCGO="/usr/local/bin/gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD=""
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-build714996541=/tmp/go-build -gno-record-gcc-switches"

What did you do?

$ GO111MODULE=off go vet cmd/vet/testdata/unsafeptr
$ GO111MODULE=on go vet cmd/vet/testdata/unsafeptr
# cmd/vet/testdata/unsafeptr
cmd/vet/testdata/unsafeptr/unsafeptr.go:12:6: possible misuse of unsafe.Pointer

What did you expect to see?

go vet produces output regardless of GO111MODULE value.

What did you see instead?

go vet does not produce output when GO111MODULE=off.

@cuonglm

This comment was marked as outdated.

Copy link
Contributor Author

commented May 17, 2019

The culprit seems to be go.sum isn't updated. After run go mod tidy, then ./make.bash, test is now passed.

$ git diff
diff --git a/src/go.sum b/src/go.sum
index 4985320126..47f7f91435 100644
--- a/src/go.sum
+++ b/src/go.sum
@@ -1,17 +1,11 @@
 golang.org/x/crypto v0.0.0-20190308221718-c2843e01d9a2/go.mod h1:djNgcEr1/C05ACkg1iLfiJU5Ep61QUkGW8qpdssI0+w=
-golang.org/x/crypto v0.0.0-20190424203555-c05e17bb3b2d h1:adrbvkTDn9rGnXg2IJDKozEpXXLZN89pdIA+Syt4/u0=
-golang.org/x/crypto v0.0.0-20190424203555-c05e17bb3b2d/go.mod h1:yigFU9vqHzYiE8UmvKecakEJjdnWj3jj499lnFckfCI=
 golang.org/x/crypto v0.0.0-20190513172903-22d7a77e9e5f h1:R423Cnkcp5JABoeemiGEPlt9tHXFfw5kvc0yqlxRPWo=
 golang.org/x/crypto v0.0.0-20190513172903-22d7a77e9e5f/go.mod h1:yigFU9vqHzYiE8UmvKecakEJjdnWj3jj499lnFckfCI=
 golang.org/x/net v0.0.0-20190404232315-eb5bcb51f2a3/go.mod h1:t9HGtf8HONx5eT2rtn7q6eTqICYqUVnKs3thJo3Qplg=
-golang.org/x/net v0.0.0-20190424112056-4829fb13d2c6 h1:FP8hkuE6yUEaJnK7O2eTuejKWwW+Rhfj80dQ2JcKxCU=
-golang.org/x/net v0.0.0-20190424112056-4829fb13d2c6/go.mod h1:t9HGtf8HONx5eT2rtn7q6eTqICYqUVnKs3thJo3Qplg=
 golang.org/x/net v0.0.0-20190514140710-3ec191127204 h1:4yG6GqBtw9C+UrLp6s2wtSniayy/Vd/3F7ffLE427XI=
 golang.org/x/net v0.0.0-20190514140710-3ec191127204/go.mod h1:t9HGtf8HONx5eT2rtn7q6eTqICYqUVnKs3thJo3Qplg=
 golang.org/x/sys v0.0.0-20190215142949-d0b11bdaac8a/go.mod h1:STP8DvDyc/dI5b8T5hshtkjS+E42TnysNCUPdjciGhY=
 golang.org/x/sys v0.0.0-20190412213103-97732733099d/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs=
-golang.org/x/sys v0.0.0-20190425145619-16072639606e h1:4ktJgTV34+N3qOZUc5fAaG3Pb11qzMm3PkAoTAgUZ2I=
-golang.org/x/sys v0.0.0-20190425145619-16072639606e/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs=
 golang.org/x/sys v0.0.0-20190514135907-3a4b5fb9f71f h1:Xab8gg26GrI/x3RNdVhVkHHM1XLyGeRBEvz4Q5x4YW8=
 golang.org/x/sys v0.0.0-20190514135907-3a4b5fb9f71f/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs=
 golang.org/x/text v0.3.0/go.mod h1:NqM8EUOU14njkJ3fqMW+pc6Ldnwhi/IjpwHt7yyuwOQ=
@cuonglm

This comment was marked as outdated.

Copy link
Contributor Author

commented May 17, 2019

Not sure why, the test now still pass even when I revert go.sum.

Anyway, do we have to update go.sum then? cc @bradfitz

If not, the issue can be closed.

@bcmills

This comment was marked as outdated.

Copy link
Member

commented May 17, 2019

If the only changes are in go.sum, that shouldn't have any significant effect. Are you sure it's not the ./make.bash alone that fixed it?

@cuonglm

This comment was marked as outdated.

Copy link
Contributor Author

commented May 17, 2019

@bcmills I think so. Here's the process:

  • When the error happened, I have GO111MODULE=off when I work inside go git repo
  • When I run go mod tidy, it complained about module is disabled.
  • So I enable GO111MODULE=on
  • Then run go mod tidy, then go did update something, and modify go.sum.
  • I did go mod vendor, nothing change in vendor dir.
  • ./make.bash, re-run the test, it passed.

@bcmills bcmills added this to the Go1.13 milestone May 17, 2019

@bcmills

This comment has been minimized.

Copy link
Member

commented May 17, 2019

@rsc has been doing some refactoring in cmd/vet. Perhaps he knows?

@bradfitz

This comment was marked as outdated.

Copy link
Member

commented May 17, 2019

https://build.golang.org/ looks happy, so this definitely seems like some local configuration problem.

@bcmills

This comment was marked as outdated.

Copy link
Member

commented May 17, 2019

vet_test.go invokes vet using go vet -vettool=<test binary>:

cmd := exec.Command(testenv.GoToolPath(t), "vet", "-vettool="+binary, arg, path.Join("cmd/vet/testdata", pkg))

Perhaps there has been a regression in the -vettool flag? The builders wouldn't detect that since they start with a fresh build every time.

(CC @jayconrod)

@cuonglm

This comment has been minimized.

Copy link
Contributor Author

commented May 17, 2019

@bradfitz I think maybe because I set GO111MODULE=off

Hope anyone haven't run go mod tidy can try this.

@bcmills

This comment was marked as outdated.

Copy link
Member

commented May 17, 2019

I really think go mod tidy is a red herring. It probably depends more on whatever version of cmd/vet you had built prior to re-running make.bash.

@cuonglm cuonglm changed the title cmd/vet: failed with current master 9be2d46422c90068db8bb9d29cb025907c6100b0 cmd/vet: test failed May 17, 2019

@cuonglm

This comment has been minimized.

Copy link
Contributor Author

commented May 17, 2019

@bcmills @bradfitz Anyway, since when go mod tidy changes the go.sum, should I send a CL to update it?

@cuonglm

This comment has been minimized.

Copy link
Contributor Author

commented May 20, 2019

@bcmills @bradfitz The error occurs again in my local

ok  	cmd/trace	0.064s
--- FAIL: TestVet (0.90s)
    --- FAIL: TestVet/print (0.27s)
        vet_test.go:162: error check failed: 
            print.go:169: missing error "Warn call has possible formatting directive %s"
            print.go:170: missing error "Warnf call needs 1 arg but has 2 args"
            print.go:171: missing error "Warnf format %r has unknown verb r"
            print.go:172: missing error "Warnf format %#s has unrecognized flag #"
            print.go:173: missing error "Warn2 call has possible formatting directive %s"
            print.go:174: missing error "Warnf2 call needs 1 arg but has 2 args"
            print.go:175: missing error "Warnf2 format %r has unknown verb r"
            print.go:176: missing error "Warnf2 format %#s has unrecognized flag #"
    --- FAIL: TestVet/unsafeptr (0.27s)
        vet_test.go:153: vet output:
        vet_test.go:154: <nil>
FAIL
FAIL	cmd/vet	1.939s
FAIL
2019/05/20 14:30:35 Failed: exit status 1

@cuonglm cuonglm changed the title cmd/vet: test failed cmd/vet: `go vet cmd/vet/testdata/unsafeptr` does not produce output when `GO111MODULE=off` May 20, 2019

@cuonglm

This comment has been minimized.

Copy link
Contributor Author

commented May 20, 2019

@bcmills @bradfitz I think I found the culprit, updated the issue.

@cuonglm cuonglm changed the title cmd/vet: `go vet cmd/vet/testdata/unsafeptr` does not produce output when `GO111MODULE=off` cmd/vet: `go vet cmd/vet/testdata/unsafeptr` does not run when `GO111MODULE=off` May 20, 2019

@cuonglm cuonglm changed the title cmd/vet: `go vet cmd/vet/testdata/unsafeptr` does not run when `GO111MODULE=off` cmd/vet: `go vet cmd/vet/testdata/unsafeptr` does not report error when `GO111MODULE=off` May 20, 2019

@bradfitz

This comment has been minimized.

Copy link
Member

commented May 20, 2019

@bcmills @bradfitz Anyway, since when go mod tidy changes the go.sum, should I send a CL to update it?

No, no need.

@cuonglm

This comment has been minimized.

Copy link
Contributor Author

commented May 20, 2019

I believe the problem comes from this line https://github.com/golang/tools/blob/9558fe4a7893c491f71cd402ea24d4a9366b8918/go/analysis/internal/analysisflags/flags.go#L56

When GO111MODULE=on, cmd/vet/testdata/unsafeptr is treated as a package path, so the flag for unsafeptr is not set. When GO111MODULE=off, cmd/vet/testdata/unsafeptr is treated as a flag toggle, the flag for unsafeptr set to false, causing it never run.

Is it a flag.Parse() bug? cc @bradfitz @bcmills

@rsc

This comment has been minimized.

Copy link
Contributor

commented May 28, 2019

It's unclear that go vet cmd/vet/testdata/unsafeptr was ever meant to be useful. The testdata directories are explicitly excluded from matching patterns like all and cmd and cmd/.... If this bug is only about the behavior on that specific argument, I'm not particularly worried.

If this is really about a real package, please give an example that is not testing a testdata directory.

@rsc

This comment has been minimized.

Copy link
Contributor

commented May 28, 2019

OK, I see that the real problem is GO111MODULE=off go test -count=1 cmd/vet failing. I will adjust the title here.

@rsc rsc changed the title cmd/vet: `go vet cmd/vet/testdata/unsafeptr` does not report error when `GO111MODULE=off` cmd/vet: `GO111MODULE=off go test -count=1 cmd/vet` fails May 28, 2019

@rsc

This comment has been minimized.

Copy link
Contributor

commented May 28, 2019

Separately, it may be that we should special-case GO111MODULE and include it in the test cache key hash. I am seeing GO111MODULE=on go test cmd/vet apparently fill a cache result used by GO111MODULE=off go test cmd/vet.

@cuonglm

This comment has been minimized.

Copy link
Contributor Author

commented May 28, 2019

@rsc GO111MODULE=off go test -count=1 cmd/vet is actually what I reported in the first time. I changed to go vet cmd/vet/testdata/unsafeptr because when I did some debug, I saw that the flag in this line https://github.com/golang/tools/blob/9558fe4a7893c491f71cd402ea24d4a9366b8918/go/analysis/internal/analysisflags/flags.go#L56 was set to false for unsafeptr if GO111MODULE=off.

I did not look much into it since #32107 (comment), would take another look when I have time.

@cuonglm

This comment has been minimized.

Copy link
Contributor Author

commented May 28, 2019

Separately, it may be that we should special-case GO111MODULE and include it in the test cache key hash. I am seeing GO111MODULE=on go test cmd/vet apparently fill a cache result used by GO111MODULE=off go test cmd/vet.

Filled #32285

@bcmills

This comment has been minimized.

Copy link
Member

commented May 29, 2019

Separately, it may be that we should special-case GO111MODULE and include it in the test cache key hash.

The test's dependency on GO111MODULE comes from the combination of being in the standard library (and hence not having any module dependencies), plus executing cmd/go as a subprocess (which adds the dependency on module-mode behavior).

Instead of hard-coding GO111MODULE in particular, I think we should make internal/testenv.GoToolPath touch all of the environment variables listed in cmd/go/internal/cfg.knownEnv. That makes the connection between the variables and the test results more explicit and much more robust: tests that execute the go command are potentially sensitive to all of the variables that the go command reads.

@andybons andybons added this to the Go1.14 milestone Jul 8, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.