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

@Merovius 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

This comment has been minimized.

Copy link
Member

@odeke-em odeke-em commented Nov 9, 2018

Thank you for reporting this issue @Merovius!

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

@dotaheor

This comment has been minimized.

Copy link

@dotaheor dotaheor commented Nov 9, 2018

same as #24721?

@Merovius

This comment has been minimized.

Copy link
Author

@Merovius Merovius commented Nov 9, 2018

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

@Merovius Merovius closed this 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
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants
You can’t perform that action at this time.