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: Embedded field names are not tracked correctly with aliased types #28655

Closed
Merovius opened this issue Nov 8, 2018 · 3 comments
Closed

Comments

@Merovius
Copy link
Contributor

Merovius commented Nov 8, 2018

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

odeke-em commented Nov 9, 2018

Thank you for reporting this issue @Merovius!

I'll tag some experts @griesemer @mdempsky @ianlancetaylor

@dotaheor
Copy link

dotaheor commented Nov 9, 2018

same as #24721?

@Merovius
Copy link
Contributor Author

Merovius commented Nov 9, 2018

Yes, you are correct, it's a dupe.

@Merovius Merovius closed this as completed Nov 9, 2018
@golang golang locked and limited conversation to collaborators Nov 9, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants