Skip to content
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

Jump to bottom

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

Open
feliixx opened this issue Feb 19, 2022 · 7 comments
Open

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

feliixx opened this issue Feb 19, 2022 · 7 comments
Labels
compiler/runtime Issues related to the Go compiler and/or runtime. NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone
Unplanned

Comments

@feliixx
Copy link
Contributor

feliixx commented Feb 19, 2022

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 seankhliao added GoCommand cmd/go NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. labels Feb 20, 2022
@seankhliao
Copy link
Member

cc @bcmills @matloob

@findleyr
Copy link
Contributor

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
Copy link
Contributor

bcmills commented Feb 22, 2022

#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
Copy link
Contributor

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
Copy link
Contributor Author

feliixx commented Feb 22, 2022

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

@thepudds
Copy link
Contributor

thepudds commented Mar 8, 2022

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
Copy link
Contributor

findleyr commented Mar 8, 2022

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.

@seankhliao seankhliao added this to the Unplanned milestone Aug 20, 2022
@bcmills bcmills changed the title cmd/go: improve error message when go version in go.mod is too low cmd/compile,go/types: improve error messages when go version is too low Oct 31, 2023
@gopherbot gopherbot added the compiler/runtime Issues related to the Go compiler and/or runtime. label Oct 31, 2023
@bcmills bcmills added compiler/runtime Issues related to the Go compiler and/or runtime. and removed GoCommand cmd/go compiler/runtime Issues related to the Go compiler and/or runtime. labels Oct 31, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
compiler/runtime Issues related to the Go compiler and/or runtime. NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Milestone
Unplanned
Development

No branches or pull requests
6 participants
@bcmills @gopherbot @feliixx @seankhliao @thepudds @findleyr