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

go/types: Generics error message doesn’t match source code when using any #49583

Closed
JeremyLoy opened this issue Nov 14, 2021 · 6 comments
Closed
Labels
FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done.
Milestone

Comments

@JeremyLoy
Copy link

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

Go 1.18 tip

Does this issue reproduce with the latest release?

No, because it includes generics

What operating system and processor architecture are you using (go env)?

Whatever the go playground runs on

What did you do?

I ran into a compiler error using generics in a switch statement.
https://gotipplay.golang.org/p/XLZZhe3QvIh

What did you expect to see?

T any was included in the error string

What did you see instead?

T interface{} was used instead. While correct, this doesn’t match the source code and can be confusing.

@JeremyLoy
Copy link
Author

It should be noted that this issue does not exist for other constraints, including custom ones

https://gotipplay.golang.org/p/26slgh8cSBp

@findleyr
Copy link
Contributor

findleyr commented Nov 15, 2021

CC @griesemer

This is because any is an alias, and the new compiler type checker has problems keeping track of aliases. The same problem exists for other alias constraints:
https://gotipplay.golang.org/p/Q6pS2FPW8W0

We have plans for 1.19 to overhaul our handling of aliases. I'm not sure we can do anything for 1.18, unfortunately -- we could try to hack the error message by using a unique pointer for the 'any' empty interface, but that is prone to unintended side effects.

I think we need to live with this for 1.18.

@gopherbot
Copy link
Contributor

Change https://golang.org/cl/363974 mentions this issue: go/types: improve error messages with any by checking pointer identity

@findleyr
Copy link
Contributor

Well, I put my speculative workaround into https://golang.org/cl/363974. It does seem to generally improve type strings, but I'm still wary that we don't fully understand the consequences of such a change.

@griesemer
Copy link
Contributor

Both the 1.17 compiler and the 1.18 compiler have trouble with aliases. This is not new. What is new is that with with 1.18 we introduce any which will likely become one of the most widely used aliases next to byte, so discrepancies in error printing will become more apparent.

The pending CL seems like a fine solution for this for now.

@griesemer griesemer added the NeedsFix The path to resolution is known, but the work has not been done. label Nov 15, 2021
@griesemer griesemer added this to the Go1.18 milestone Nov 15, 2021
@gopherbot
Copy link
Contributor

Change https://golang.org/cl/364194 mentions this issue: all: prepare for formatting any as 'any' in type strings

gopherbot pushed a commit to golang/tools that referenced this issue Nov 16, 2021
Make a couple of small changes to support keeping track of the
predeclared any by pointer identity, and formatting it as 'any'. This
should allow x/tools trybots to pass on CL 363974.

Updates golang/go#49583

Change-Id: I79cffee6adbf000a7251dbea4091fdd7b8fdcf0a
Reviewed-on: https://go-review.googlesource.com/c/tools/+/364194
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
@seankhliao seankhliao changed the title Generics error message doesn’t match source code when using any go/types: Generics error message doesn’t match source code when using any Nov 16, 2021
@golang golang locked and limited conversation to collaborators Jun 23, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done.
Projects
None yet
Development

No branches or pull requests

4 participants