cmd/compile: errors involving aliased types should use the alias name

[bcmills]

In https://golang.org/cl/63277, @ianlancetaylor notes:

Right now if I compile

package p

type myByte = byte
var _ myByte = "uc"

I get

foo.go:4:16: cannot use "uc" (type string) as type byte in assignment

Arguably that is wrong. For example, gccgo prints

foo.go:4:5: error: incompatible type in initialization (cannot use type string as type myByte)

If we first fix the compiler to use the alias name in the error message as I think it should, then perhaps we can apply this change while retaining good error messages.

Concretely: if the compiler reports a type error involving an alias, it should use the aliased name of the type rather than the underlying/canonical name.

That would allow us to use type aliases for a larger subset of C types (#13467) without producing overly-cryptic error messages for mismatched types.

[ianlancetaylor]

CC @griesemer @mdempsky

[myitcv]

A random drive-by thought; instead of using just the alias name, use some combination of the alias name and the underlying defined type. Taking your example:

foo.go:4:5: error: incompatible type in initialization (cannot use type string as type myByte (-> byte))

🚲 -shedding welcomed on the format.

Reason being, the error message is then clear that myByte is an alias (type myByte = byte) as opposed to a defined type (type myByte byte).

[mdempsky]

This is a known limitation of cmd/compile (and go/types), but I don't think we filed an issue, so thanks for that!

Within cmd/compile, the way we implement

type myByte = byte

is having the types.Sym for myByte simply defined to byte's OTYPE gc.Node. The corresponding types.Type, however, has no knowledge of the name "myByte".

There is a precedent within the compiler that uint8 and byte as well as int32 and rune (which are effectively aliases too) are actually represented as separate types.Type objects, and then at a few spots within the compiler we special case these two (e.g., eqtype for type identity).

Perhaps the easiest fix is to generalize those special cases to any kind of type aliases.

[myitcv]

Another (perhaps obvious) observation in support of @bcmills's proposal is consistency with documentation:

package playground

import (
	"github.com/myitcv/playground/internal/a"
)

type T = a.S

func Hello(s T) {
}

func Fail() {
	Hello(5)
}

fails to compile with the message:

# github.com/myitcv/playground
./playground.go:13:8: cannot use 5 (type int) as type a.S in argument to Hello

But the godoc is:

func Hello(s T)

[gopherbot]

Change https://golang.org/cl/98476 mentions this issue: cmd/compile: prevent detection of wrong duplicates

[namusyaka]

I'm interested in this problem, so I'm thinking about it.

[griesemer]

I agree this would be a "nice to have" but I don't think this is of particular high priority. I also think it's quite subtle to get right in general (requires complete understanding of type representation in compiler).

[JavierZunzunegui]

This came up in golang-nuts.