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: missing hint to check go.mod if language version < 1.18 and declare a generic type or func #51531

Closed
thepudds opened this issue Mar 7, 2022 · 7 comments
Closed

cmd/compile: missing hint to check go.mod if language version < 1.18 and declare a generic type or func #51531

thepudds opened this issue Mar 7, 2022 · 7 comments
Labels
FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done.
Milestone
Go1.18

Comments

@thepudds
Copy link
Contributor

thepudds commented Mar 7, 2022

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

Tip:

go version devel go1.19-63bd6f68e6 Mon Mar 7 15:02:48 2022

Does this issue reproduce with the latest release?

Yes.

What did you see?

I happened to notice a very experienced gopher this morning struggling a bit to figure out why they couldn't use generics:

I'm experimenting with generics again, with the release candidate. But now I see "type parameters require go 1.18 or later" when I try to build code with type parameters. Do I need a build flag?

Kind of a weird error to see when go version reports:
go version go1.18rc1 linux/amd64

The troubleshooting in the #generics Slack channel went back and forth a bit on whether or not the right version of Go was being used. Someone else later suggested that the go.mod language version needed to be updated, which was the issue.

I poked briefly at this using tip.

Friendly error

You get a friendly message suggesting to "check go.mod" if you instantiate a generic type or func:

type instantiation requires go1.18 or later (-lang was set to go1.17; check go.mod)

Example: https://go.dev/play/p/aXHOlSclSgT?v=gotip

Less friendly error

However, if you only declare a generic type or func without instantiation, you just get the following error (without the friendly suggestion to check go.mod):

type parameters require go1.18 or later

Example: https://go.dev/play/p/2Q1ZHdBWiPG?v=gotip

FWIW, it's clear many more gophers are going to be using generics soon 😅, and addressing this might be a small bit of polish that could avoid some toe stubbing (and perhaps head off some issues getting filed or questions on the mailing list and so on).

Obviously, someone will eventually instantiate something, but it is probably not unusual to start with a declaration first and try to compile before trying to instantiate.
@thepudds
Copy link
Contributor Author

thepudds commented Mar 7, 2022

FWIW, I have a cmd/compile CL that seems to address the specific examples above, which I will hopefully send in a bit.

thepudds added a commit to thepudds/go that referenced this issue Mar 7, 2022
@thepudds
cmd/compile/internal/types2: more consistently provide hint to check …
a8116f1 
…go.mod if language version < 1.18

If you attempt to instantiate a generic type or func and run 'go build'
with a language version < 1.18 in the 'go' directive inside the go.mod file,
cmd/compile emits a friendly message that includes the suggestion to 'check go.mod':

  type instantiation requires go1.18 or later (-lang was set to go1.17; check go.mod)

However, if the code instead only declares a generic type or func without
instantiating, cmd/compile currently emits a less friendly message:

  type parameters require go1.18 or later

With this CL, the error in that situation becomes:

  type parameter requires go1\.18 or later (-lang was set to go1\.17; check go.mod)

Within cmd/compile/internal/types2, it already calls check.versionErrorf in a dozen or so
places, including three existing calls to check.versionErrorf within typeset.go (e.g., for
embedding a constraint interface).

This CL adds two more calls to check.versionErrorf, replacing calls to check.softErrorf.
Both check.versionErrorf and check.softErrorf call check.err(at, <string>, true) after
massaging the string message.

Fixes golang#51531
thepudds added a commit to thepudds/go that referenced this issue Mar 7, 2022
@thepudds
cmd/compile/internal/types2: more consistently provide hint to check …
f8d93ae 
…go.mod if language version < 1.18

If you attempt to instantiate a generic type or func and run 'go build'
with a language version < 1.18 in the 'go' directive inside the go.mod file,
cmd/compile emits a friendly message that includes the suggestion to 'check go.mod':

  type instantiation requires go1.18 or later (-lang was set to go1.17; check go.mod)

However, if the code instead only declares a generic type or func without
instantiating, cmd/compile currently emits a less friendly message:

  type parameters require go1.18 or later

With this CL, the error in that situation becomes:

  type parameter requires go1\.18 or later (-lang was set to go1\.17; check go.mod)

Within cmd/compile/internal/types2, it already calls check.versionErrorf in a dozen or so
places, including three existing calls to check.versionErrorf within typeset.go (e.g., for
embedding a constraint interface).

This CL adds two more calls to check.versionErrorf, replacing calls to check.softErrorf.
Both check.versionErrorf and check.softErrorf call check.err(at, <string>, true) after
massaging the string message.

Fixes golang#51531
@thepudds thepudds mentioned this issue Mar 7, 2022
Closed
@gopherbot
Copy link

Change https://go.dev/cl/390578 mentions this issue: cmd/compile/internal/types2: more consistently provide hint to check go.mod if language version < 1.18

thepudds added a commit to thepudds/go that referenced this issue Mar 8, 2022
@thepudds
cmd/compile/internal/types2: more consistently provide hint to check …
b0b7c13 
…go.mod if language version < 1.18

If you attempt to instantiate a generic type or func and run 'go build'
with a language version < 1.18 in the 'go' directive inside the go.mod
file, cmd/compile emits a friendly message that includes the suggestion
to 'check go.mod':

  type instantiation requires go1.18 or later (-lang was set to go1.17; check go.mod)

However, if the code instead only declares a generic type or func without
instantiating, cmd/compile currently emits a less friendly message:

  type parameters require go1.18 or later

With this CL, the error in that situation becomes:

  type parameter requires go1\.18 or later (-lang was set to go1\.17; check go.mod)

Within cmd/compile/internal/types2, it already calls check.versionErrorf
in a dozen or so places, including three existing calls to
check.versionErrorf within typeset.go (e.g., for embedding a constraint
interface).

This CL adds two more calls to check.versionErrorf, replacing calls to
check.softErrorf. Both check.versionErrorf and check.softErrorf call
check.err(at, <string>, true) after massaging the string message.

Fixes golang#51531
@dmitshur dmitshur added the NeedsFix The path to resolution is known, but the work has not been done. label Mar 8, 2022
@dmitshur dmitshur added this to the Go1.19 milestone Mar 8, 2022
@thepudds
Copy link
Contributor Author

thepudds commented Mar 8, 2022

Hi @dmitshur and @findleyr, I don’t have a precise sense of (a) how close release is and (b) how high the bar is for changes for 1.18…

I suspect the answers are (a) “very close“ and (b) “very high“, but I at least wanted to ask if this issue is worth at least evaluating briefly.

FWIW, the number of gophers using generics is probably about to increase by a large factor, with a diversity of skillsets and experience (vs. the early adopters playing with them so far on average might tend to be more experienced).

Regarding the new message, one of the gophers in the #generics Slack channel commented:

Such a small thing, but this is likely to be a huge UX improvement for folks coming to 1.18 without full context.

In any event, the answer probably is “not even close“, but at least wanted to ask.

@findleyr
Copy link
Contributor

findleyr commented Mar 8, 2022

CC @griesemer

I am not sure what meets the bar at this point, as we have been focusing on release blockers. In my opinion this change could be safe to cherry-pick, but I defer to the release team.

@dmitshur
Copy link
Contributor

dmitshur commented Mar 9, 2022 •
edited

@thepudds Thanks for flagging this issue fix as potentially worth retargeting for Go 1.18. (We are close to the final release, and the bar is very high as described here.)

Having looked at the issue and CL closely: it's fixing an error message, and it will be most useful during people's initial experience with generics. The fix looks safe to me, has already gone through code review. If it's okay with @findleyr and @griesemer, I believe there's room to fit it in, so I'll tentatively move this to 1.18 milestone and insert it in #51460. (Our other options will be to consider it for backport to a 1.18.1 or later minor release, or leave it for 1.19.)

@dmitshur dmitshur modified the milestones: Go1.19, Go1.18 Mar 9, 2022
@dmitshur dmitshur mentioned this issue Mar 9, 2022
Closed
33 tasks
@gopherbot
Copy link

Change https://go.dev/cl/390959 mentions this issue: [release-branch.go1.18] cmd/compile/internal/types2: more consistently print "check go.mod" if language version < 1.18

@griesemer
Copy link
Contributor

I'm ok with this being cherry-picked. I agree that it will be helpful to new users of generics.

gopherbot pushed a commit that referenced this issue Mar 9, 2022
@thepudds @dmitshur
[release-branch.go1.18] cmd/compile/internal/types2: more consistentl…
92644ff 
…y print "check go.mod" if language version < 1.18

If you attempt to instantiate a generic type or func and run 'go build'
with a language version < 1.18 in the 'go' directive inside the go.mod
file, cmd/compile emits a friendly message that includes the suggestion
to 'check go.mod':

    type instantiation requires go1.18 or later (-lang was set to go1.17; check go.mod)

However, if the code instead only declares a generic type or func
without instantiating, cmd/compile currently emits a less friendly
message:

    type parameters require go1.18 or later

With this CL, the error in that situation becomes:

    type parameter requires go1.18 or later (-lang was set to go1.17; check go.mod)

Within cmd/compile/internal/types2, it already calls check.versionErrorf
in a dozen or so places, including three existing calls to
check.versionErrorf within typeset.go (e.g., for embedding a constraint
interface).

This CL adds two more calls to check.versionErrorf, replacing calls to
check.softErrorf. Both check.versionErrorf and check.softErrorf call
check.err(at, <string>, true) after massaging the string message.

Fixes #51531

Change-Id: If54e179f5952b97701d1dfde4abb08101de07811
GitHub-Last-Rev: b0b7c13
GitHub-Pull-Request: #51536
Reviewed-on: https://go-review.googlesource.com/c/go/+/390578
Reviewed-by: Robert Griesemer <gri@golang.org>
Trust: Robert Findley <rfindley@google.com>
(cherry picked from commit d3070a7)
Reviewed-on: https://go-review.googlesource.com/c/go/+/390959
Trust: Dmitri Shuralyov <dmitshur@golang.org>
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
@golang golang locked and limited conversation to collaborators Mar 9, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done.
Projects
None yet
Milestone
Go1.18
5 participants
@dmitshur @griesemer @gopherbot @thepudds @findleyr