Description
When the system Go version is newer than the GOTOOLCHAIN go version, we observed the x/tools/go/packages picks up the system Go version as the go version. This can cause the package to use the incompatible go list command. @matloob found this is because x/tools/internal/gocommand.GoVersion called by x/tools/go/packages.(*golistState).getGoVersion, uses GO111MODULE=off which prevents correct go version computation depending on toolchain switch.
This bug prevents gopls (v0.15.3, v0.16.0, v0.16.1) from operating with old go versions like go1.19 if the system Go version is newer. (e.g. using -pgo flag that doesn't exist in go1.19)
This will potentially break the future gopls versions if users rely on the GOTOOLCHAIN to switch to go versions and go/packages ends up using new go list flags that do not exist in the GOTOOLCHAIN version but exist in the system Go version.
We first need to understand why GoVersion uses GO111MODULE=off.
Metadata
Metadata
Assignees
Labels
Type
Projects
Milestone
Relationships
Development
Participants
Activity
gabyhelp commentedon Jul 17, 2024
Related Issues and Documentation
(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)
findleyr commentedon Nov 11, 2024
This is not going to get fixed for gopls@v0.17.0.
@matloob do you understand why GoVersion uses GO111MODULE=off?
adonovan commentedon Apr 18, 2025
The actual logic dates from https://go.dev/cl/263985, but that doesn't explain why.
@matloob, do you know?
jakebailey commentedon Apr 18, 2025
I'm not matloob (😅), but I remember reading this code a really long time ago when it was first sent, and remember it being slightly faster to invoke
go listand others without module mode enabled. When I test that with hyperfine, it's barely true, maybe 0.1ms.However, actually digging, that code actually stemmed from CL 253799 where it was previously the code for
modfileFlagExists, which traces back to CL 211937, then eventually all the way to CL 212477 where it was seemingly just to deal with the temp modfile back when that was a thing. (And I guess, not in this case for perf; I was probably thining ofgo envbeing slow, which is still true by a bit.)matloob commentedon Apr 18, 2025
I am matloob but I think @jakebailey has a better answer than I do!
I really can't think of a good reason to set
GO111MODULE=offfor go version. Before we had toolchain switching/selection,go version's behavior shouldn't have changed at all depending on the value ofGO111MODULE.gopherbot commentedon Apr 18, 2025
Change https://go.dev/cl/666715 mentions this issue:
internal/gocommand: don't disable Go modulesadonovan commentedon Apr 18, 2025
Thanks. I'll mail you a CL to remove it.