With 1.18 (which adds types.Config.GoVersion), we'd like to better support a workflow that uses gopls built at a recent version of Go to develop projects that target running at an older version of Go.
#50688 is necessary but not sufficient: setting types.Config.GoVersion will not catch usage of standard library APIs that were added in later Go versions. We need to add additional diagnostics to gopls.
The right way to do this is probably via an analyzer that has a flag configuring its target language version. This makes it easier for users to eventually leverage this functionality outside of gopls, or turn it of/on within gopls.
High level idea:
Add a new analyzer (initially in x/tools/internal/lsp/analysis) that reports usage of standard library APIs that do not exist at a target language version. It can read from GOROOT/api to build the list of accepted APIs.
Either infer the target language version for a package from go.mod, or (more likely) expose a setting to configure it. Unlike for types.Config.GoVersion, reading go.mod is probably not good enough here, because IIRC the Go command does not enforce restrictions on standard library API use, so we would disagree. Perhaps we should not have a gopls`-specific configuration option, but rather expose a more general pattern for configuring analyzer flags.
The text was updated successfully, but these errors were encountered:
Compare #46136, which proposes a similar warning for cmd/vet.
gopherbot
added
Tools
This label describes issues relating to any tools in the x/tools repository.
gopls
Issues related to the Go language server, gopls.
labels
Jan 19, 2022
With 1.18 (which adds
types.Config.GoVersion
), we'd like to better support a workflow that uses gopls built at a recent version of Go to develop projects that target running at an older version of Go.#50688 is necessary but not sufficient: setting
types.Config.GoVersion
will not catch usage of standard library APIs that were added in later Go versions. We need to add additional diagnostics to gopls.The right way to do this is probably via an analyzer that has a flag configuring its target language version. This makes it easier for users to eventually leverage this functionality outside of gopls, or turn it of/on within gopls.
High level idea:
x/tools/internal/lsp/analysis
) that reports usage of standard library APIs that do not exist at a target language version. It can read fromGOROOT/api
to build the list of accepted APIs.go.mod
, or (more likely) expose a setting to configure it. Unlike fortypes.Config.GoVersion
, readinggo.mod is probably not good enough here, because IIRC the Go command does not enforce restrictions on standard library API use, so we would disagree. Perhaps we should not have a
gopls`-specific configuration option, but rather expose a more general pattern for configuring analyzer flags.The text was updated successfully, but these errors were encountered: