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

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

Open
bcmills opened this Issue Sep 13, 2017 · 7 comments

Comments

Projects
None yet
7 participants
@bcmills
Member

bcmills commented Sep 13, 2017

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 ianlancetaylor added this to the Go1.10 milestone Sep 13, 2017

@ianlancetaylor

This comment has been minimized.

Contributor

ianlancetaylor commented Sep 13, 2017

@myitcv

This comment has been minimized.

Member

myitcv commented Sep 13, 2017

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 comment has been minimized.

Member

mdempsky commented Sep 13, 2017

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

This comment has been minimized.

Member

myitcv commented Oct 20, 2017

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)

@mdempsky mdempsky modified the milestones: Go1.10, Go1.11 Nov 29, 2017

@gopherbot

This comment has been minimized.

gopherbot commented Mar 4, 2018

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

gopherbot pushed a commit that referenced this issue Mar 7, 2018

cmd/compile: prevent detection of wrong duplicates
by including *types.Type in typeVal.

Updates #21866
Fixes #24159

Change-Id: I2f8cac252d88d43e723124f2867b1410b7abab7b
Reviewed-on: https://go-review.googlesource.com/98476
Run-TryBot: Kunpei Sakai <namusyaka@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
@namusyaka

This comment has been minimized.

Member

namusyaka commented Mar 10, 2018

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

@griesemer

This comment has been minimized.

Contributor

griesemer commented Mar 12, 2018

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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment