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.

Sign up for GitHub

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

Jump to bottom

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

Open
findleyr opened this issue Oct 28, 2024 · 4 comments · May be fixed by golang/website#301
Open

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

findleyr opened this issue Oct 28, 2024 · 4 comments · May be fixed by golang/website#301
Labels
Documentation NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone
Unreleased

Comments

@findleyr
Copy link
Member

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
Copy link

Related Issues and Documentation

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

@findleyr findleyr added GoCommand cmd/go and removed GoCommand cmd/go labels Oct 28, 2024
@cagedmantis cagedmantis added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Oct 29, 2024
@cagedmantis cagedmantis added this to the Unreleased milestone Oct 29, 2024
@samthanawalla
Copy link
Contributor

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
Copy link

I'd like to work on this issue.

chansuke added a commit to chansuke/website_golang that referenced this issue Oct 30, 2024
@chansuke
_content/blog: update GODEBUG documentation to clarify go.work behavior
daafb25 
This change updates the documentation to explain how GODEBUG settings
are configured based on the Go version specified in either the go.mod
or go.work file, with go.work taking priority. This clarification helps
developers understand the interaction of GODEBUG settings with different
Go workspace configurations.

Fixes golang/go#70083
@chansuke chansuke linked a pull request Oct 30, 2024 that will close this issue
Open
@gopherbot
Copy link
Contributor

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Documentation NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Milestone
Unreleased
Development

Successfully merging a pull request may close this issue.

_content/blog: update GODEBUG documentation to clarify go.work behavior chansuke/website_golang
6 participants
@cagedmantis @chansuke @gopherbot @samthanawalla @findleyr @gabyhelp