Skip to content

x/tools/gopls: design UX around version skew resulting from the forward compatibility proposal #61185

Open
@findleyr

Description

@findleyr

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 its go.mod file, whenever version 1.N of go is released, so that go 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

Metadata

Metadata

Assignees

Labels

ToolsThis label describes issues relating to any tools in the x/tools repository.goplsIssues related to the Go language server, gopls.gopls/metadataIssues related to metadata loading in gopls

Type

No type

Projects

No projects

Relationships

None yet

Development

No branches or pull requests

Issue actions