cmd/compile: internal compiler error: expected struct { int } value to have type struct { int }

[zigo101]

What version of Go are you using (go version)?

$ go version
go version go1.18beta1 linux/amd64

Does this issue reproduce with the latest release?

In 1.18 beta 1, not in 1.17.5,

What did you do?

package main

type Int = int

type A = struct{ int }
type B = struct{ Int }

func main() {
	var x, y interface{} = A{}, B{}
	println(x == y) // true
}

What did you expect to see?

compiles okay

What did you see instead?

crashes compiler

[ALTree]

cc @danscales

Tentatively labelling as release-blocker to prevent it from slipping through, but feel free to reassess its priority.

[aclements]

I was able to reproduce this on linux/amd64. The failure is:

./50190.go:9:31: internal compiler error: expected struct { int } value to have type struct { int }

goroutine 1 [running]:
runtime/debug.Stack()
	/home/austin/go.dev/src/runtime/debug/stack.go:24 +0x65
cmd/compile/internal/base.FatalfAt({0x3fa7e0?, 0xc0?}, {0xd2c6c5, 0x1b}, {0xc000613430, 0x2, 0x2})
	/home/austin/go.dev/src/cmd/compile/internal/base/print.go:227 +0x1ca
cmd/compile/internal/base.Fatalf(...)
	/home/austin/go.dev/src/cmd/compile/internal/base/print.go:196
cmd/compile/internal/walk.(*orderState).newTemp(0xc0005ee040, 0xc0003fa7e0, 0x0)
	/home/austin/go.dev/src/cmd/compile/internal/walk/order.go:84 +0x138
cmd/compile/internal/walk.(*orderState).copyExpr1(0xc0005ee040, {0xe91400, 0xc000144680}, 0xf0?)
	/home/austin/go.dev/src/cmd/compile/internal/walk/order.go:120 +0x50
cmd/compile/internal/walk.(*orderState).copyExpr(...)
	/home/austin/go.dev/src/cmd/compile/internal/walk/order.go:101
cmd/compile/internal/walk.(*orderState).addrTemp(0xe91400?, {0xe91400, 0xc000144680})
	/home/austin/go.dev/src/cmd/compile/internal/walk/order.go:258 +0x1f7
cmd/compile/internal/walk.(*orderState).expr1(0xc0005ee040, {0xe91590, 0xc0004281e0?}, {0xe925f8, 0xc00041dd40})
	/home/austin/go.dev/src/cmd/compile/internal/walk/order.go:1187 +0x64a
cmd/compile/internal/walk.(*orderState).expr(0xe90c30?, {0xe91590, 0xc0004281e0}, {0xe925f8, 0xc00041dd40})
	/home/austin/go.dev/src/cmd/compile/internal/walk/order.go:1096 +0x7b
cmd/compile/internal/walk.(*orderState).stmt(0xc0005ee040, {0xe90c30?, 0xc000428190?})
	/home/austin/go.dev/src/cmd/compile/internal/walk/order.go:619 +0x117a
cmd/compile/internal/walk.(*orderState).stmtList(0xced360?, {0xc000144780, 0x5, 0x8})
	/home/austin/go.dev/src/cmd/compile/internal/walk/order.go:398 +0x85
cmd/compile/internal/walk.orderBlock(0xc00041ec70, 0xc0005da240)
	/home/austin/go.dev/src/cmd/compile/internal/walk/order.go:468 +0x85
cmd/compile/internal/walk.order(0xc00041ec60)
	/home/austin/go.dev/src/cmd/compile/internal/walk/order.go:67 +0x9b
cmd/compile/internal/walk.Walk(0xc00041ec60)
	/home/austin/go.dev/src/cmd/compile/internal/walk/walk.go:27 +0x50
cmd/compile/internal/gc.prepareFunc(0xc00041ec60)
	/home/austin/go.dev/src/cmd/compile/internal/gc/compile.go:92 +0x6d
cmd/compile/internal/gc.enqueueFunc(0xc00041ec60)
	/home/austin/go.dev/src/cmd/compile/internal/gc/compile.go:66 +0x2fd
cmd/compile/internal/gc.Main(0xd4a7e8)
	/home/austin/go.dev/src/cmd/compile/internal/gc/main.go:309 +0xf97
main.main()
	/home/austin/go.dev/src/cmd/compile/main.go:55 +0xdd

[cuonglm]

This ICE dues to change in ed647b1

But it sounds like an existing compiler bug to me, since when struct{ int } and struct{ Int } should be identical, the compiler reports false even with 1.17 and before.

cc @mdempsky

[zigo101]

@cuonglm The logic bug is #24721

[cuonglm]

@go101 Oh, the spec said that:

Two struct types are identical if they have the same sequence of fields, and if corresponding fields have the same names, and identical types, and identical tags

So that includes embedded fields.

[zigo101]

@cuonglm I don't deny it is a comparison bug.

[cuonglm]

@go101 According to the spec, and what @griesemer explained in #24721 (comment), struct{ int } and struct{ Int } are not identical.

[zigo101]

I mean I agree with the conclusion. ;)

[danscales]

@mdempsky Do you want to take a look at this bug, especially if it might be related to your change:

https://go-review.googlesource.com/c/go/+/330911

[danscales]

Assigning to you Matthew, feel free to unassign or assign to me/Keith if it decide it doesn't make sense for you to analyze/fix.

[gopherbot]

Change https://golang.org/cl/372914 mentions this issue: cmd/compile: unique LinkString for renamed, embedded fields

[bcmills]

The fix in CL 372914 introduced a race that is now showing up in the racecompile builder. Reopening until that is addressed.

[gopherbot]

Change https://golang.org/cl/378434 mentions this issue: cmd/compile: unique LinkString for renamed, embedded fields