x/tools/go/packages: confusing error when loading source newer than toolchain used to build application

[adonovan]

When an application that links go/packages is built with a go1.18 toolchain, it includes go1.18's type checker (go/types). If the application is then used with version go1.20 of the go command on the PATH, go list will report source files that may rely on language features of go1.20 (such as recent additions to the unsafe package), which aren't supported by its type checker. The errors are confusing; see #55045.

Instead, go/packages should either instruct go list to select files using release tags corresponding to the version of the type checker linked with it, or should otherwise detect and report the version skew in a straightforward message.

See also:

• cmd/go: add a flag to set (or exclude) release tags #52078 (flag to set release tags)
• x/tools/gopls: add support for a target language version, and drop support for building at legacy Go versions #50825 (gopls legacy version support)
• x/tools/go/packages: confusing error when loading source newer than toolchain used to build application #55883 (go/packages confusing error)

[gopherbot]

Change https://go.dev/cl/435356 mentions this issue: go/packages: warn if 'go list' on PATH is too new

[heschi]

It seems strange to issue a warning without knowing what the caller is going to do with the results of the call. What if they only want to list the files? Returning a hard error if NeedTypes is specified makes more sense to me, FWIW.

[adonovan]

Yes, the same thought occurred to me, though I'm still not sure a hard error is warranted. What if someone updated their go toolchain but is still only using it to build older code? It seems rough that they would have to rebuild any apps that use go/packages. Perhaps we should continue to issue a warning but only if the parser is used. (The problem is broader than NeedTypes.) Or even defer the version check until parsing or type checking fails, and append it to the parse/type errors?