cmd/compile: missing hint to check go.mod if language version < 1.18 and declare a generic type or func #51531
Comments
|
FWIW, I have a cmd/compile CL that seems to address the specific examples above, which I will hopefully send in a bit. |
…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
…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
|
Change https://go.dev/cl/390578 mentions this issue: |
…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
added
the
NeedsFix
|
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:
In any event, the answer probably is “not even close“, but at least wanted to ask. |
|
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. |
|
@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.) |
|
Change https://go.dev/cl/390959 mentions this issue: |
|
I'm ok with this being cherry-picked. I agree that it will be helpful to new users of generics. |
…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 <[email protected]>
Trust: Robert Findley <[email protected]>
(cherry picked from commit d3070a7)
Reviewed-on: https://go-review.googlesource.com/c/go/+/390959
Trust: Dmitri Shuralyov <[email protected]>
Run-TryBot: Dmitri Shuralyov <[email protected]>
TryBot-Result: Gopher Robot <[email protected]>
What version of Go are you using (
go version)?Tip:
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:
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:
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):
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.
The text was updated successfully, but these errors were encountered: