cmd/compile: crash on pointer conversion in call to mapaccess2

[julianiewiejska]

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:

<autogenerated>:1: cannot use &.autotmp_19 (type *struct { netip.addr netip.uint128; netip.z *intern.Value }) as type *netip.Addr in argument to runtime.mapaccess2

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-

[ianlancetaylor]

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})
}

<autogenerated>:1: cannot use &.autotmp_17 (type *struct { hi uint64; lo uint64; z *byte }) as type *Addr in argument to runtime.mapaccess2

[ianlancetaylor]

@gopherbot Please open a backport to 1.18

This is a compiler crash on valid code.

[gopherbot]

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.

[blackgreen100]

it seems the crash reproduces also on mapassign, and also when the key's underlying type is some composite type with more than one member:

• struct { x, y int } crashes
• struct { x int } does not crash
• [2]uint64 crashes
• [1]uint64 does not crash

[wdvxdr1123]

I noticed this issue has been fixed in 115c3bf.

[mdempsky]

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