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

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

Open
bcmills opened this issue Sep 13, 2017 · 8 comments
Open

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

bcmills opened this issue Sep 13, 2017 · 8 comments
Labels
compiler/runtime Issues related to the Go compiler and/or runtime. NeedsFix The path to resolution is known, but the work has not been done.
Milestone

Comments

@bcmills
Copy link
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 the NeedsFix The path to resolution is known, but the work has not been done. label Sep 13, 2017
@ianlancetaylor ianlancetaylor added this to the Go1.10 milestone Sep 13, 2017
@ianlancetaylor
Copy link
Contributor

CC @griesemer @mdempsky

@myitcv
Copy link
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
Copy link
Member

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
Copy link
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
Copy link

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
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
Copy link
Member

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

@griesemer
Copy link
Contributor

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
Copy link

This came up in golang-nuts.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
compiler/runtime Issues related to the Go compiler and/or runtime. NeedsFix The path to resolution is known, but the work has not been done.
Projects
None yet
Development

No branches or pull requests

8 participants