cmd/go: document interaction of go.work with GODEBUG

findleyr commented 2 weeks ago

We recently encountered this confusing scenario when working in the x/tools repository

In order to use a go.work file to work on gopls (which has go 1.23.1 in its go.mod file), one has to have at least go1.23.1 in the go.work file.
x/tools assumes that it's default GODEBUG behavior implies gotypesalias=0, and has tests such ./internal/aliases.TestNewAlias that assume this.

Therefore, there's no way to have a go.work file for which both x/tools and x/tools/gopls tests pass. This is a problem in x/tools, because these tests also fail when run from a different main module that uses go1.23 (see #70082).

Nevertheless, go.dev/blog/compat says the following:

A program’s GODEBUG settings are configured to match the Go version listed in the main package’s go.mod file. If your program’s go.mod file says go 1.20 and you update to a Go 1.21 toolchain, any GODEBUG-controlled behaviors changed in Go 1.21 will retain their old Go 1.20 behavior until you change the go.mod to say go 1.21.

We should update that documentation to explain how godebug interacts with go.work files.

CC @timothy-king @matloob @samthanawalla

gabyhelp commented 2 weeks ago

Related Issues and Documentation

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

samthanawalla commented 2 weeks ago

This is confusing, I agree. The documentation should mention that the default GODEBUG settings are determined by the go version in either the go.work or go.mod with go.work taking priority.

Here's a code pointer to this behavior: https://cs.opensource.google/go/go/+/master:src/cmd/go/internal/load/godebug.go;l=51;bpv=0;bpt=1

chansuke commented 1 week ago

I'd like to work on this issue.

gopherbot commented 1 week ago

Change https://go.dev/cl/623416 mentions this issue: _content/blog: update GODEBUG documentation to clarify go.work behavior

golang / go

cmd/go: document interaction of go.work with GODEBUG #70083