x/tools/gopls: warn if language version is newer than compile version

[findleyr]

As suggested by @matta in #68248, we should warn when the version of Go used to compile gopls is older than the language version implied by the go.mod file. A diagnostic on the go directive of the go.mod file probably suffices.

FWIW, I reported a similar issue in staticcheck. There, the fix to build with go1.23rc1 worked as well.

@dominikh also added code to staticcheck that will report an error if the tool is used on a go module requiring versions of go newer than what the tool was built with. gopls could consider a similar check.

Originally posted by @matta in https://github.com/golang/go/issues/68248#issuecomment-2198396157

[gabyhelp]

Related Issues

• x/tools/gopls: match new language versions for type checking #63472 (closed)
• x/tools/gopls: improve error message when user needs newer go version #61673 (closed)
• x/tools/gopls: warn about standard library API usage based on Go version #50689
• x/tools/gopls: upgrade to staticcheck@v0.3.0 #52159 (closed)
• x/tools/gopls: set types.Config.GoVersion based on go.mod #50688 (closed)
• x/tools/gopls: add support for a target language version, and drop support for building at legacy Go versions #50825 (closed)
• x/tools/gopls: once Go 1.23 is released, require Go 1.21+ (forward compatibility) to build gopls #65917
• x/tools/gopls: design UX around version skew resulting from the forward compatibility proposal #61185

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

[dominikh]

Note that Staticcheck primarily has its own logic for this to produce better error messages. go/types already complains when the asked-for language version is newer than the version of go/types, but in Go 1.22, the error message read package requires newer Go version go1.23. Starting with Go 1.23, it seems to produce a better error message: /home/dominikh/prj/src/example.com/foo.go:3:1: package requires newer Go version go1.24 (application built with go1.23).

8121604559035734c9677d5281bbdac8b1c17a1e seems to be the commit that improved the message.

[matta]

Will a diagnostic in go.mod be enough? In my experience, "show all workspace diagnostics" is not consistently supported (or used) in editors. They show diagnostics only for the files the editor has opened.

In the case of #68248, I built with go1.23rc1 on the command line with go build ./... and saw all was well, then opened up a .go file in the project and saw the diagnostic from gopls. At that point, I did not open go.mod to check for additional diagnostics there.

In @dominikh's example above, maybe the error would appear for every file, which would cover it, I think.