I can reproduce on tip da4d585 and 1.13.5 and 1.12.14. Does not repo on 1.11.13

GO111MODULE=on go list -m in a non module directory prints command-line-arguments instead of go list -m: not using modules. Does not happen with GO111MODULE=auto or GO111MODULE=off

cc @heschik

This is coming from the go command, not go/packages -- the code linked above is just trying to mimic that behavior.

@bcmills, @jayconrod will know better but I think this is supposed to fail and instead is outputting a dummy value.

Confirming that this is a dummy value. It's the name of the main module when the go command runs in module mode outside a module (no go.mod file and GO111MODULE=on).

Perhaps it should be an error instead? go list -m all and go list -m ... report errors when run outside a module. We have a special case that suppresses matches for command-line-arguments and patterns that would match it like c....

command-line-arguments is the package name that you get when you invoke go build or go run with a list of files instead of a package name.

The reason I chose that for go list -m outside of a module is that the module name is still significant in that case: in particular, the name of the main module affects which internal imports the files are allowed to use. (A module name of command-line-arguments implies that the files are only allowed to access packages in modules with paths beginning with the name command-line-arguments, of which there are none.)

The module name command-line-arguments is also more consistent from the perspective of debug information: for modules other than std, the package path is nearly always an extension of the module path, and the package path in this case has been command-line-arguments since long before module support.