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.
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 becausex/tools/internal/gocommand.GoVersion
called byx/tools/go/packages.(*golistState).getGoVersion
, usesGO111MODULE=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
.cc @golang/tools-team @matloob @findleyr