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

[heschik]

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"

[heschik]

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