Description
This issue follows up on discussion in https://go.dev/cl/507975, where go/types is being updated to fail type-checking if the required Go version (as configured by types.Config.GoVersion
) is greater than the Go version of the standard library (e.g. the version used to compile gopls).
This is the right change for go/types, because an older version of the type checker cannot type check code that was written for a newer version of Go.
However, we aim for an invariant in gopls that "if the Go command works, gopls works" (see also #57979). Previously, we didn't have to worry about the impact of version skew on this invariant, because the version of go
in the user's environment is usually the same as the version of go used to compile gopls. So if gopls was producing confusing errors, the go command would also produce confusing errors.
But with forward compatibility (#57001), I think it will frequently be the case that the go command will work correctly, because it was automatically upgraded, yet gopls will fail.
We need to design and test an appropriate UX when users encounter this skew. Some questions to consider:
- Should we endeavor to release a new version of gopls with
go 1.N
in itsgo.mod
file, whenever version1.N
of go is released, so thatgo install golang.org/x/tools/gopls@latest
will always have a version of gopls compatible with all published versions of Go? - Should we pop-up a message prompting the user to reinstall gopls, whenever a new Go version is published?
- Should we pop-up a message prompting the user to reinstall gopls, whenever they work on code that is intended for a newer go version?
- Should we allow gopls to still partially function, by artificially decreasing the version we pass as
types.Config.GoVersion
? - Should gopls always re-install itself with the latest toolchain, whenever a newer toolchain is available?
CC @golang/tools-team