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

bcmills opened this issue Sep 13, 2017 · 8 comments

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

bcmills opened this issue Sep 13, 2017 · 8 comments


Copy link

@bcmills bcmills commented Sep 13, 2017

In, @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
Copy link

@ianlancetaylor ianlancetaylor commented Sep 13, 2017

Copy link

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

Copy link

@mdempsky 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.

Copy link

@myitcv myitcv commented Oct 20, 2017

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

package playground

import (

type T = a.S

func Hello(s T) {

func Fail() {

fails to compile with the message:

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

@gopherbot gopherbot commented Mar 4, 2018

Change 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
Run-TryBot: Kunpei Sakai <>
TryBot-Result: Gobot Gobot <>
Reviewed-by: Matthew Dempsky <>
Copy link

@namusyaka namusyaka commented Mar 10, 2018

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

Copy link

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

Copy link

@JavierZunzunegui JavierZunzunegui commented Sep 8, 2020

This came up in golang-nuts.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
8 participants