Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cmd/go: document the meaning of solitary "command-line-arguments" #36043

Open
kortschak opened this issue Dec 8, 2019 · 9 comments
Open

cmd/go: document the meaning of solitary "command-line-arguments" #36043

kortschak opened this issue Dec 8, 2019 · 9 comments

Comments

@kortschak
Copy link
Contributor

@kortschak kortschak commented Dec 8, 2019

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

$ go version

Does this issue reproduce with the latest release?

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

go env Output
$ go env
GO111MODULE="on"
GOARCH="amd64"
GOBIN="/home/user/bin"
GOCACHE="/home/user/.cache/go-build"
GOENV="/home/user/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/user"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/home/user/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/home/user/go/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-build773661967=/tmp/go-build -gno-record-gcc-switches"

What did you do?

~ $ go list -m
command-line-arguments

and look for "command-line-arguments" in documentation and the source tree.

What did you expect to see?

An explanation of the significance of the output.

What did you see instead?

Crickets (though also some bread crumbs in the source and commit messages).

It would be nice if the meaning were properly documented.

@AlexRouSg

This comment was marked as outdated.

@go101

This comment was marked as off-topic.

@AlexRouSg

This comment was marked as outdated.

@AlexRouSg
Copy link
Contributor

@AlexRouSg AlexRouSg commented Dec 8, 2019

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

@kortschak

This comment was marked as off-topic.

@AlexRouSg

This comment was marked as off-topic.

@heschik
Copy link
Contributor

@heschik heschik commented Dec 9, 2019

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.

@jayconrod
Copy link
Contributor

@jayconrod jayconrod commented Dec 9, 2019

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....

@bcmills
Copy link
Member

@bcmills bcmills commented Dec 9, 2019

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
8 participants
You can’t perform that action at this time.