cmd/go: panics listing ./... in GOROOT/src

[heschi]

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

$ ~/go/bin/go version   
go version devel +f77e7ed7e3 Wed Jan 15 22:02:44 2020 +0000 linux/amd64

Does this issue reproduce with the latest release?

Yes, 1.13.4.

What did you do?

cd $(go env GOROOT)/src; go list ./...

What did you expect to see?

Some packages

What did you see instead?

panic: loadPackageData called with empty package path

goroutine 33 [running]:
cmd/go/internal/load.loadPackageData(0x0, 0x0, 0x0, 0x0, 0xc000026034, 0x24, 0x0, 0x0, 0x0, 0x0, ...)
	go/src/cmd/go/internal/load/pkg.go:649 +0x625
cmd/go/internal/load.(*preload).preloadMatches.func1(0xc0004aeba0, 0x0, 0x0)
	go/src/cmd/go/internal/load/pkg.go:847 +0x80
created by cmd/go/internal/load.(*preload).preloadMatches
	go/src/cmd/go/internal/load/pkg.go:845 +0x165

@jayconrod @bcmills, marking as a tentative release blocker since it breaks gopls on the stdlib.

[dmitshur]

Does this issue reproduce with the latest release?

Yes, 1.13.4.

I can't reproduce this on go1.13.6 darwin/amd64.

Other than your OS being Linux, perhaps there's something different about your environment. Is your GO111MODULE env var set to something, if so, what? What does cd $(go env GOROOT)/src; go list or cd $(go env GOROOT)/src; go list -m print?

[dmitshur]

I tried on linux/amd64 wit the updated instructions and it didn't reproduce there for me:

$ go version
go version go1.13.6 linux/amd64
$ cd $(go env GOROOT)/src; go list ./...
archive/tar
archive/zip
bufio
bytes
compress/bzip2
compress/flate
compress/gzip
compress/lzw
compress/zlib
container/heap
[...]
$ echo $?
0

go env Output

$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/dmitshur/.cache/go-build"
GOENV="/home/dmitshur/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/dmitshur/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/usr/local/go/src/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-build992502533=/tmp/go-build -gno-record-gcc-switches"

[heschi]

I have a habit of leaving toy .go files in $GOROOT/src, and apparently that's a bad idea. Definitely not a release blocker.

[jayconrod]

cc @matloob

So it sounds like we should either ignore this package or report an error (leaning toward error).

In GOPATH mode, if there are .go files in $GOPATH/src, there's a weird mix of behavior. go install ./... won't install anything, but go list ./... reports a path. If a file has a syntax error, that gets reported.

[gopherbot]

Change https://golang.org/cl/216381 mentions this issue: cmd/go: emit an error for extraneous files in GOROOT/src

[matloob]

I put together a change that emits an error

[bcmills]

Thinking about this some more: I don't think there is any clear, concise error message we can emit for go test ./... that explains what the problem actually is, and I don't think folks actually intend for those files to be treated as a package anyway.

We should certainly emit an error for go test ., but I think we should just leave the directory out of the matches for ./..., just like we do for the special builtin package (which also cannot be imported).

Coincidentally, that approach also simplifies the code somewhat.

[gopherbot]

Change https://golang.org/cl/185345 mentions this issue: cmd/go: rationalize errors in internal/load and internal/modload