cmd/compile,go/types: improve error messages when go version is too low

[feliixx]

What version of Go are you using (go version)?

go version go1.18rc1 linux/amd64

Does this issue reproduce with the latest release?

yes

What did you do?

Tried to play with generics after installing go 1.18 RC1, but was a little confused by the error message
when trying to use 1.18 feature like the any keyword because I totally forgot about the go version in go.mod.

./main.go:30:25: undeclared name: any (requires version go1.18 or later)

Mentioning go.mod in the error message would have helped fixing the error directly instead of having to re-check my config and search for this error message etc

What did you expect to see?

./main.go:30:25: undeclared name: any (requires version go1.18 or later, current min version in go.mod: go1.16)

What did you see instead?

./main.go:30:25: undeclared name: any (requires version go1.18 or later)

[seankhliao]

cc @bcmills @matloob

[findleyr]

This error is coming from go/types. @feliixx did you encounter this in VS Code (or some other editor that uses gopls)?

CC @hyangah @suzmue

[bcmills]

#48966 is somewhat related, in that the go command could produce a better error for a mismatched version.

#46136 is very closely related, in that the vet command (and/or gopls) could flag uses of identifiers that are too new — any just happens to be a special built-in one.

[findleyr]

My 2c: the fundamental problem here is that the compiler and/or type checker can't assume a build system, and so generally avoids being prescriptive in this way. With that said, cmd/compile/internal/types2 does mention go.mod versions directly. I opted not to include that in go/types, which is more likely to be used with packages that don't have an associated go.mod file.

Ideally we'd expose an error code or wrapped error so that the caller (the go command or gopls) could offer prescriptive suggestions. We have been planning this for go/types, and so have an unexported field on go/types.Error that holds such an error code. For now we can make do with the combination of this field and parsing error strings (see also #51086).

Aside: this is actually a good example of where a single error code probably wouldn't suffice. The actual error is "undeclared name"; a possible secondary error is "unsupported feature" (because "any" is unsupported), and it would be nice to surface in a structured way the version at which this feature was introduced.

CC @griesemer

[feliixx]

@findleyr no I wasn't using gopls, just running
go build directly in my terminal

[thepudds]

Hi @findleyr, it sounds like this was cmd/compile (and not gopls).

I sent https://go.dev/cl/390578 yesterday to try to handle some similar cases for cmd/compile, and from a quick look, it seemed like a similar fix would be possible for use of any and comparable.

I will probably try a CL for this issue here as well, but wanted to check here first in case that is not sensible for some reason (e.g., based on what you mentioned in #51270 (comment) above).

[findleyr]

Hi @thepudds I think making this change in types2 (a.k.a. cmd/compile) is fine. For philosophical reasons, go/types does not mention go.mod (it is build-system agnostic), but I think we've decided that it's fine for the compiler to do so.