.github: issue template doesn't describe toolchain selection

[rhysh]

Three days after the release of go1.25.0, we've had two new dups of #74111 (#75018 and #75027). Users are updating their go.mod files to reference go1.25.0, trying to set GOEXPERIMENT for one of the three new experiments, and running a version of the cmd/go command between go1.24.0 and go1.24.4 (with fips140 support, but without the fix for #74111).

Users could fix this by updating the version of the go command they initially invoke to be go1.24.5 or later, provided that they're able to diagnose the problem.

That's (somewhat) hard to figure out, since the output of go version and go env refers to the version of Go that's in place after toolchain selection has succeeded. The issue templates don't hint at this at all (for instance, by asking for the output of GOTOOLCHAIN=local go version). Maybe we should call that out in the issue template, or provide some other defense against bugs in very old versions of the go executable now that automatic toolchain selection has removed the usual need to update them.

CC @dmitshur @seankhliao @prattmic @golang/command-line

[prattmic]

Just throwing out ideas, maybe we could have go version -v (or some other flag) print the version of the initial toolchain in addition to the final toolchain.

Then in the template ask for GOFLAGS=-v go version to avoid choking old versions (https://cs.opensource.google/go/go/+/master:src/cmd/go/internal/version/version.go;l=68).

This would be a very long term fix though, as it requires updates to the initial toolchain.

Asking for GOTOOLCHAIN=local go version && go version in the template is probably more straightforward.

[seankhliao]

previously #66518

I still think long term it'd be nice to have an extra read only env like GOHOSTTOOLCHAIN.
Right now we can tell it's a switched version by looking at GOROOT, but can't tell what the original version was.
We can even make this a behavior of newer versions where they query the pre-switch version that invoked them...

[dmitshur]

The GODEBUG=toolchaintrace=1 feature which is already added in Go 1.24 sounds pretty close to the behavior suggested above.

Perhaps GOTOOLCHAIN=local go version && GODEBUG=toolchaintrace=1 go version would get the most context, since as @prattmic noted GODEBUG=toolchaintrace=1 go version alone doesn't seem to include the initial toolchain version. A downside is that it's a much bigger command to run than go version alone.

[gabyhelp]

Related Issues

• cmd/go: crash on unknown GOEXPERIMENT during toolchain selection [1.24 backport] #74113 (closed)

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

[prattmic]

Another downside to these fancy commands is that they don't work as written on Windows:

C:\b\s\w\ir\go\bin>GOTOOLCHAIN=local go version && GODEBUG=toolchaintrace=1 go version
'GOTOOLCHAIN' is not recognized as an internal or external command,
operable program or batch file.

So we'd need to include slightly different instructions for Windows.

[TapirLiu]

This is really confusing. Maybe separating a go mod version command from the go version command could help resolve this.

[cagedmantis]

@golang/runtime