cmd/compile: crash on pointer conversion in call to mapaccess2 #51840
Comments
|
Here is a standalone test case. CC @randall77 @mdempsky package main
type Addr struct {
hi uint64
lo uint64
z *byte
}
func EqualMap[M1, M2 ~map[K]V, K, V comparable](m1 M1, m2 M2) bool {
for k, v1 := range m1 {
if v2, ok := m2[k]; !ok || v1 != v2 {
return false
}
}
return true
}
type Set[T comparable] map[T]struct{}
func NewSet[T comparable](items ...T) Set[T] {
return nil
}
func (s Set[T]) Equals(other Set[T]) bool {
return EqualMap(s, other)
}
func main() {
NewSet[Addr](Addr{0, 0, nil})
} |
ianlancetaylor
changed the title
ianlancetaylor
added
NeedsInvestigation
|
@gopherbot Please open a backport to 1.18 This is a compiler crash on valid code. |
|
Backport issue(s) opened: #51849 (for 1.18). Remember to create the cherry-pick CL(s) as soon as the patch is submitted to master, according to https://go.dev/wiki/MinorReleases. |
|
it seems the crash reproduces also on
|
Based upon expanding the `StringSet` type. Note that we cannot substitute uses of `map[T]struct{}` where `T` is an interface because interface types are [not comparable](golang/go#51338), even though the `map[T]struct{}` version works.
`AreEqual` is a standalone function at the moment because making it a method [crashes the compiler](golang/go#51840).
|
I noticed this issue has been fixed in 115c3bf. |
|
@wdvxdr1123 Thanks, for the heads up. That's unexpected, but a believable effect. If anyone wants to contribute a CL adding the failure cases as a regression test, that would be great. (Just add a file $GOROOT/test/fixedbugs/issue51840.go that demonstrates the previously failing code now compiles correctly. Look for other "// compile" or "// run" test cases in the directory, if you need inspiration.) Otherwise, I'll prepare one on Monday. |
|
Change https://go.dev/cl/404914 mentions this issue: |
|
Change https://go.dev/cl/405436 mentions this issue: |
This CL is a manual backport of CLs 403837 and 404914 to Go 1.18. CL 403837 was intended just as a simplification CL, but evidently it also fixed #51840. However, for backporting to Go 1.18, the existing logic needs to be preserved to support -G=0 mode (which still relies on Ntype). Fixes #51849. Change-Id: Ib060b0bc67ecf26de8a65d5b4d2f8a65cd547517 Reviewed-on: https://go-review.googlesource.com/c/go/+/405436 Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Keith Randall <khr@google.com>
|
Change https://go.dev/cl/417616 mentions this issue: |
This reverts CL 405436 (commit e1b14f5). Fixes #53883. Updates #51840. Change-Id: Ide5a9568a7ae5b449ef154c29b69699a7e4b3f6b Reviewed-on: https://go-review.googlesource.com/c/go/+/417616 Reviewed-by: David Chase <drchase@google.com> Run-TryBot: Cherry Mui <cherryyz@google.com> Reviewed-by: Jenny Rakoczy <jenny@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org>
What version of Go are you using (
go version)?go version go1.18 linux/amd64
Does this issue reproduce with the latest release?
yes
What did you do?
https://go.dev/play/p/_Q4fOpnr5rn
What did you expect to see?
Code compiles and runs without errors.
What did you see instead?
Code produces error:
Other remarks
This seems to only happen when maps.Equal is used in the method even if the method is not called. There is no error when it is called directly: https://go.dev/play/p/KlpiWS96MA-
The text was updated successfully, but these errors were encountered: