cmd/go: go list -m reports command-line-arguments when called outside a module

[perillo]

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

$ go version
go version go1.14beta1 linux/amd64

Does this issue reproduce with the latest release?

Yes.

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

go env Output

$ go env
GO111MODULE="on"
GOARCH="amd64"
GOBIN="/home/manlio/.local/bin"
GOCACHE="/home/manlio/.cache/go-build"
GOENV="/home/manlio/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GONOPROXY="github.com/perillo"
GONOSUMDB="github.com/perillo"
GOOS="linux"
GOPATH="/home/manlio/.local/lib/go:/home/manlio/src/go"
GOPRIVATE="github.com/perillo"
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/home/manlio/sdk/go1.14beta1"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/home/manlio/sdk/go1.14beta1/pkg/tool/linux_amd64"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/dev/null"
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-build475655411=/tmp/go-build -gno-record-gcc-switches"
GOROOT/bin/go version: go version go1.14beta1 linux/amd64
GOROOT/bin/go tool compile -V: compile version go1.14beta1
uname -sr: Linux 5.4.15-arch1-1
/usr/lib/libc.so.6: GNU C Library (GNU libc) stable release version 2.30.
gdb --version: GNU gdb (GDB) 8.3.1

What did you do?

In a directory with no reachable go.mod:

go list -m -json

What did you expect to see?

go list should report an error, since there is no module.

What did you see instead?

{
	"Path": "command-line-arguments",
	"Main": true
}

This really feels wrong for me.

[bcmills]

Per https://tip.golang.org/cmd/go/#hdr-Package_lists_and_patterns:

As a special case, if the package list is a list of .go files from a single directory, the command is applied to a single synthesized package made up of exactly those files, ignoring any build constraints in those files and ignoring any other files in the directory.

Running a small .go source file (or a small list of files) that has no dependencies outside of the standard library is one of the most common use-cases for the go command outside of a module, and is one of the only operations you can do when outside of a module.

The effective package path for a list of .go source files has been command-line-arguments since well before module mode, and (for every module except std) the module path is a prefix of the package path. That is why go list -m reports that module path: command-line-arguments is the only supported path in that context.

I think @jayconrod recently suggested that we consider also making go run . work when outside of a module. If we decide to do that (and if we can decide what the package path should be in that case), then perhaps we should also reconsider what the output of go list -m should be when outside of a module.

(CC @matloob)

[perillo]

Sorry, I forgot to report that there are no files in the current working directory.

In my case, there is no go.mod file and no .go files. Moreover I ran go list -m, where the package list is empty. In this case the documentation says:

If no import paths are given, the action applies to the package in the current directory.

But there is no package, in my case.

[perillo]

https://github.com/golang/go/blob/master/doc/modules.md#resolving-a-package-to-a-module says that:

At least one file with the .go extension must be present in a directory for it to be considered a package.

And go list fails with

go: cannot find main module