Skip to content

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

Open
golang/website
#301
@findleyr

Description

@findleyr

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    DocumentationIssues describing a change to documentation.NeedsInvestigationSomeone must examine and confirm this is a valid issue and not a duplicate of an existing one.

    Type

    No type

    Projects

    No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions