-
Notifications
You must be signed in to change notification settings - Fork 17.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
x/tools/gopls: add support for a target language version, and drop support for building at legacy Go versions #50825
Comments
#55092 should definitely help here.
I would personally support this. Anyone stuck on older and unsupported Go versions could similarly stick to a slightly older version of gopls, I would imagine. Perhaps any IDEs which try to automatically update Go and gopls could learn about this too. It's also worth noting that this "supporting two Go versions" policy is pretty standard elsewhere, including the dependencies of gopls like gofumpt. I just tagged v0.4.0 and it supports Go 1.18 or later, for example, which now I'm thinking might be a problem for gopls to update if it aims to support four releases for a bit longer. |
Change https://go.dev/cl/435356 mentions this issue: |
Not a problem. This has happened in the past, and we simply don't link gofumpt at older Go versions (similar for staticcheck). |
An application that links in version 1.18 of (say) go/types cannot process Go source files reported by version 1.19 of 'go list'. There is no way to tell go list to behave as if it was go1.18, so for now we proceed with parsing/typechecking but, in case of errors, we issue an additional informative diagnostic. Fixes golang/go#55883 Fixes golang/go#55045 Updates golang/go#50825 Updates golang/go#52078 Change-Id: I5fd99b09742c136f4db7f71d2a75e4cdb730460d Reviewed-on: https://go-review.googlesource.com/c/tools/+/435356 gopls-CI: kokoro <[email protected]> Reviewed-by: Robert Findley <[email protected]> TryBot-Result: Gopher Robot <[email protected]> Run-TryBot: Alan Donovan <[email protected]> Reviewed-by: Bryan Mills <[email protected]> Auto-Submit: Alan Donovan <[email protected]> Reviewed-by: Zvonimir Pavlinovic <[email protected]>
Change https://go.dev/cl/439836 mentions this issue: |
Add a showMessage notification when the Go version in PATH is too old. Also delete the unused View.Rebuild method. Updates golang/go#50825 Change-Id: I279a04f021a0f8ddb09fcfe299fbab8d10e8c022 Reviewed-on: https://go-review.googlesource.com/c/tools/+/439836 Run-TryBot: Robert Findley <[email protected]> Auto-Submit: Robert Findley <[email protected]> TryBot-Result: Gopher Robot <[email protected]> gopls-CI: kokoro <[email protected]> Reviewed-by: Hyang-Ah Hana Kim <[email protected]>
Change https://go.dev/cl/588763 mentions this issue: |
Background
Right now the gopls team supports building gopls using the four most recent major Go versions, though technically we still maintain support for Go 1.12+. This is significantly longer than the support window of the Go project itself, which covers only the two most recent major Go versions.
In the past, we've seen evidence (in the form of bug reports or survey results) that our users are supporting older Go versions for their applications/libraries. Whether or not this is a good thing is moot: there were reasons out of our control (e.g. cloud services support windows) that caused our users to support older Go versions. Absent a strong reason to break compatibility, the gopls team continued to maintain compatibility with older Go versions because the only way to provide accurate functionality for an older Go version was to build gopls at that Go version.
This legacy support causes significant friction for the team, notably:
go.work
at older Go versionsgo/parser
orgo/types
Proposal
We should provide features that make it easier to build gopls with a recent Go version but target development at an earlier Go version. We should then begin the process of dropping support for building gopls at older Go versions. As we do this, we should document and announce the final version of gopls that supports being built at each Go version.
Eventually we should align our support window with the Go project: the two most recent Go versions. This will allow us to turn down our legacy CI.
Supporting a target language version
With Go 1.18, the
types.Config.GoVersion
field allows us to specify an accepted language version forgo/types
, analogous to the compiler-lang
flag. This removes a key blocker to this proposal.Specifically, there are three components to providing accurate gopls functionality for older target Go versions:
go/types
) errors based on the target language version (x/tools/gopls: set types.Config.GoVersion based on go.mod #50688)Of these, (1) and (2) are now straightforward, as described by the linked issues. (3) is harder, because AFAIK
x/tools/go/packages
(and thego
command) does not provide a way to specify release tags -- they are baked into thego
binary. Issue #42504 would be useful here: gopls could do its own post-processing of build tags.In the meantime, we can either declare that we won't be able to satisfy (3), or support using a different
go
command forgo/packages
than was used to build gopls. In principle simply using a differentgo
version forgo list
should work, but may introduce difficult combinatorial problems. Using a different version ofgo
forgo/packages
would actually handle both (2) and (3) above, so we should explore this option.We should of course update our installation instructions to document this workflow.
Deriving the target language version(s)
We can derive the target language version from the applicable
go.mod
, thego
version inPATH
, or from explicit gopls configuration. We may use more than one of these sources, but ideally we would avoid any additional gopls configuration.Dropping support for older Go versions
We can take the following steps to ease the impact on our users when we drop support for a Go version:
CC @golang/tools-team
The text was updated successfully, but these errors were encountered: