What did you do?
mero@hix ~/tmp/bug$ cat bug1.go
package main
import "fmt"
func main() {
type T1 int
type T2 = T1
a := struct{ T1 }{}
b := struct{ T2 }{}
fmt.Println(a == b)
}
mero@hix ~/tmp/bug$ go run bug1.go
# command-line-arguments
./bug1.go:10:16: invalid operation: a == b (mismatched types struct { T1 } and struct { T1 })
mero@hix ~/tmp/bug$ go run -compiler=gccgo bug1.go
# command-line-arguments
./bug1.go:10:16: error: incompatible types in binary expression
fmt.Println(a == b)
^
mero@hix ~/tmp/bug$ cat bug2.go
package main
import "fmt"
func main() {
type T1 int
type T2 = T1
a := interface{}(struct{ T1 }{})
b := interface{}(struct{ T2 }{})
fmt.Println(a == b)
}
mero@hix ~/tmp/bug$ go run bug2.go
true
mero@hix ~/tmp/bug$ go run -compiler=gccgo bug2.go
false
What did you expect to see?
bug2.go behaving the same when compiled with gc and gccgo - probably printing "false".
The spec says:
The unqualified type name acts as the field name.
The type alias proposal is even more explicit about this. Lastly, both compilers reject bug1.go as not identical types, so gc is behaving internally inconsistent here, by saying the types are not identical at compile-time, but that they are at run-time.
What did you see instead?
gc seems to not assign the correct field name, if the TypeName is an alias.
Also, this is slightly related to #21866 - as in, both have roughly the same root-cause, I'd guess.
Does this issue reproduce with the latest release (go1.11.2)?
Yes. I also, more specifically, reproduced this with the same Go release that my gccgo version supports (as far as I can tell, 1.10).
System details
go version devel +7da1f7addf Thu Nov 8 08:19:48 2018 +0000 linux/amd64
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/mero/.cache/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/mero"
GOPROXY=""
GORACE=""
GOROOT="/home/mero/go"
GOTMPDIR=""
GOTOOLDIR="/home/mero/go/pkg/tool/linux_amd64"
GCCGO="/usr/bin/gccgo"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD=""
GOROOT/bin/go version: go version devel +7da1f7addf Thu Nov 8 08:19:48 2018 +0000 linux/amd64
GOROOT/bin/go tool compile -V: compile version devel +7da1f7addf Thu Nov 8 08:19:48 2018 +0000
uname -sr: Linux 4.18.16-200.fc28.x86_64
LSB Version: :core-4.1-amd64:core-4.1-noarch
Distributor ID: Fedora
Description: Fedora release 28 (Twenty Eight)
Release: 28
Codename: TwentyEight
/lib64/libc.so.6: GNU C Library (GNU libc) stable release version 2.27.
gdb --version: GNU gdb (GDB) Fedora 8.1.1-3.fc28
What did you do?
What did you expect to see?
bug2.gobehaving the same when compiled with gc and gccgo - probably printing "false".The spec says:
The type alias proposal is even more explicit about this. Lastly, both compilers reject
bug1.goas not identical types, so gc is behaving internally inconsistent here, by saying the types are not identical at compile-time, but that they are at run-time.What did you see instead?
gc seems to not assign the correct field name, if the TypeName is an alias.
Also, this is slightly related to #21866 - as in, both have roughly the same root-cause, I'd guess.
Does this issue reproduce with the latest release (go1.11.2)?
Yes. I also, more specifically, reproduced this with the same Go release that my gccgo version supports (as far as I can tell, 1.10).
System details