cmd/go: list prints leading underscore when given testdata directories

[mvdan]

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

go version devel +c96c2a39bb Thu Oct 11 04:45:18 2018 +0000 linux/amd64

Does this issue reproduce with the latest release?

Yes - checked on 1.11.1.

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

GOARCH="amd64"
GOBIN=""
GOCACHE="/home/mvdan/go/cache"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/mvdan/go/land:/home/mvdan/go"
GOPROXY=""
GORACE=""
GOROOT="/home/mvdan/tip"
GOTMPDIR=""
GOTOOLDIR="/home/mvdan/tip/pkg/tool/linux_amd64"
GCCGO="gccgo"
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-build430264220=/tmp/go-build -gno-record-gcc-switches"

What did you do?

Run go list ./testdata both in GOPATH and module mode.

Copy and paste this into a shell:

GOPATH=$(mktemp -d)
mkdir -p $GOPATH/src/foo.com/bar
cd $GOPATH/src/foo.com/bar
mkdir testdata
echo 'package foo' >testdata/foo.go
go list ./testdata
export GO111MODULE=on
go mod init foo.com/bar
go list ./testdata

What did you expect to see?

The same result in both cases.

What did you see instead?

$ GOPATH=$(mktemp -d)
$ mkdir -p $GOPATH/src/foo.com/bar
$ cd $GOPATH/src/foo.com/bar
$ mkdir testdata
$ echo 'package foo' >testdata/foo.go
$ go list ./testdata
_/tmp/tmp.rr2RmmLENC/src/foo.com/bar/testdata
$ export GO111MODULE=on
$ go mod init foo.com/bar
go: creating new go.mod: module foo.com/bar
$ go list ./testdata
foo.com/bar/testdata

Note that this only happens with testdata directories containing Go files. It doesn't happen with other directories that shouldn't be importable packages, like _foo.

First, I'm confused by the weird _/$GOPATH/src/$IMPORT_PATH string, when I was expecting just the import path. I couldn't find any piece of documentation about this format.

Second, I'm even more confused as to why this behaves differently depending on whether we're in GOPATH or module-aware mode.

This bug report is the result of digging a bit after the tests on a linter of mine were failing on 1.10. This was because go/types.Type.String() was returning mvdan.cc/unparam/check/testdata.FooType on Go 1.11 with GO111MODULE=on, but _/home/travis/gopath/src/mvdan.cc/unparam/check/testdata.FooType on Go 1.10 with GO111MODULE=on (since the env var is ignored there).

/cc @bcmills (and thanks to @rogpeppe and @myitcv, who helped me investigate)

[mvdan]

Also, I realise that this _/full/path/to/directory format is used for Go packages outside of GOPATH when we're in GOPATH mode. However, that shouldn't apply here, as we're clearly inside $GOPATH/src.

[mvdan]

I forgot to properly label this.

[bcmills]

As far as I can tell, this affects only GOPATH mode and only in pretty unusual edge-cases. I would be surprised if we are able to fix it before GOPATH mode is removed.

[mvdan]

@bcmills sounds good. I think this issue only made sense a year ago, when GOPATH was still used in the majority of projects. Perhaps it can be left open for others to find it, until GOPATH mode is dropped.

[mvdan]

I don't think anyone uses GOPATH mode these days.