x/tools/cmd/stringer: cannot import vendored dependencies

[stub42]

Please answer these questions before submitting your issue. Thanks!

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

go version go1.8.3 linux/amd64

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

Ubuntu Linux, amd64

What did you do?

Attempted to run golang.org/x/tools/cmd/stringer on package importing vendored dependencies

What did you expect to see?

The tool work as expected

What did you see instead?

While 'go build' and all other tools seem fine with depdencies vendored in $GOPATH/src/vendor, stringer fails with import errors:

$ go build plinth/auth
$ go get golang.org/x/tools/cmd/stringer
$ go generate plinth/auth
stringer: checking package: auth.go:8:2: could not import golang.org/x/net/context (can't find import: vendor/golang.org/x/net/context)
src/plinth/auth/auth.go:37: running "stringer": exit status 1
$ stringer -type Role $GOPATH/src/plinth/auth
stringer: checking package: [...]/src/plinth/auth/auth.go:8:2: could not import golang.org/x/net/context (can't find import: vendor/golang.org/x/net/context)
$ ls $GOPATH/src/vendor/golang.org/x/net/context
context.go  context_test.go  ctxhttp  go17.go  go19.go  pre_go17.go  pre_go19.go  withtimeout_test.go

[ChimeraCoder]

We're running into this issue as well. It only manifests under Go 1.8, as can be seen here: https://travis-ci.org/stripe/veneur/builds/278659663. It's reproducible locally by changing the Dockerfile in the corresponding pull request to use Go 1.8 instead of Go 1.9. It happens even if the package that it can't find (in this case, github.com/gogo/protobuf/proto) is installed with go install.

The stringer importer uses the default Go importer for 1.8, but not for 1.9.

Running go install in the current project (not on the package it can't import, but on the one in which the import is vendored) before running Stringer fixes the problem.

I tried to take a stab at fixing this in stringer, though I'm not sure why the behavior of go/importer itself changed between 1.8 and 1.9 in this way. Could someone point me in the right direction here?

[ChimeraCoder]

This problem was fixed in Go 1.10, but it was reintroduced recently. I'm pretty sure the commit which introduced it was golang/tools@ffe8890, which reverts CL 40403.

The commit was reverted in order to solve #25650, though it reintroduces #10249, which is related.

I can't comment on that issue because it was originally locked due to age - it was reopened two days ago, but it's still limited to collaborators.

[cespare]

@ChimeraCoder I unlocked #10249.