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: internal compiler error: expected struct { int } value to have type struct { int } #50190

Closed
go101 opened this issue Dec 15, 2021 · 13 comments
Labels
FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done. release-blocker
Milestone

Comments

@go101
Copy link

go101 commented Dec 15, 2021

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 ALTree added this to the Go1.18 milestone Dec 15, 2021
@ALTree ALTree added NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. release-blocker labels Dec 15, 2021
@ALTree
Copy link
Member

ALTree commented Dec 15, 2021

cc @danscales

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

@aclements
Copy link
Member

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
Copy link
Member

cuonglm commented Dec 15, 2021

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

@go101
Copy link
Author

go101 commented Dec 15, 2021

@cuonglm The logic bug is #24721

@cuonglm
Copy link
Member

cuonglm commented Dec 15, 2021

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

@go101
Copy link
Author

go101 commented Dec 15, 2021

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

@cuonglm
Copy link
Member

cuonglm commented Dec 15, 2021

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

@go101
Copy link
Author

go101 commented Dec 15, 2021

I mean I agree with the conclusion. ;)

@cherrymui cherrymui changed the title cmd/compile: crashes cmd/compile: internal compiler error: expected struct { int } value to have type struct { int } Dec 15, 2021
@danscales
Copy link
Contributor

@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
Copy link
Contributor

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

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

@bcmills bcmills reopened this Jan 10, 2022
@bcmills
Copy link
Contributor

bcmills commented Jan 10, 2022

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

@gopherbot
Copy link

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

@dmitshur dmitshur added NeedsFix The path to resolution is known, but the work has not been done. and removed NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. labels May 12, 2022
jproberts pushed a commit to jproberts/go that referenced this issue Jun 21, 2022
Using type aliases, it's possible to create structs with embedded
fields that have no corresponding type literal notation. However, we
still need to generate a unique name for these types to use for linker
symbols. This CL introduces a new "struct{ Name = Type }" syntax for
use in LinkString formatting to represent these types.

Fixes golang#50190.

Change-Id: I025ceb09a86e00b7583d3b9885d612f5d6cb44fe
Reviewed-on: https://go-review.googlesource.com/c/go/+/372914
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Trust: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Dan Scales <danscales@google.com>
Trust: Dan Scales <danscales@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
jproberts pushed a commit to jproberts/go that referenced this issue Jun 21, 2022
Using type aliases, it's possible to create structs with embedded
fields that have no corresponding type literal notation. However, we
still need to generate a unique name for these types to use for linker
symbols. This CL introduces a new "struct{ Name = Type }" syntax for
use in LinkString formatting to represent these types.

Reattempt at CL 372914, which was rolled back due to race-y
LocalPkg.Lookup call that isn't safe for concurrency.

Fixes golang#50190.

Change-Id: I0b7fd81e1b0b3199a6afcffde96ade42495ad8d1
Reviewed-on: https://go-review.googlesource.com/c/go/+/378434
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
@golang golang locked and limited conversation to collaborators Jun 22, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done. release-blocker
Projects
None yet
Development

No branches or pull requests

9 participants