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

[JeremyLoy]

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]

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

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

[findleyr]

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]

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

[findleyr]

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]

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.

[gopherbot]

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