runtime: wrong type assertion result when using generic types

[disksing]

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

$ go version
go version go1.18 darwin/amd64

Does this issue reproduce with the latest release?

yes

What operating system and processor architecture are you using (go env)?

doesn't matter. It can reproduce on the go playground.

go env Output

$ go env

What did you do?

https://go.dev/play/p/A9VuqCpJ7r5

What did you expect to see?

As S does not have method name M1 or M2, it should not panic.

What did you see instead?

Panic and output iface1. I also noticed that if I rename IFace2 to AFace2, the result is panic and output iface2.

[griesemer]

Simplified version (playground):

package main

func f[B any](b B) {
	if b1, ok := any(b).(interface{ m1() }); ok {
		panic(1)
		_ = b1.(B) // <<< removing this type assertion makes this code work
	}
	if b2, ok := any(b).(interface{ m2() }); ok {
		panic(2)
		_ = b2.(B) // <<< removing this type assertion makes this code work
	}
}

type S struct{}

func (S) m3() {}

func main() {
	f(S{})
}

Replacing the type parameter B with S produces the expected result (no panic).
cc: @mdempsky (for trying with unified IR), @randall77

[mdempsky]

Test cases run correctly (i.e., exit quietly with success) with GOEXPERIMENT=unified.

[heschi]

Tentatively marking release blocker.

[mdempsky]

S and m3 aren't even needed. Just f(0) repros the issue too.

[mdempsky]

It seems to happen for any named type. E.g., instantiating B as []int doesn't cause problems, but instantiating it as SliceInt does.

[ianlancetaylor]

@gopherbot Please open backport to 1.18.

This appears to be incorrect code generation, so we should backport the fix when we have one.

[gopherbot]

Backport issue(s) opened: #51738 (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.

[gopherbot]

Change https://go.dev/cl/399058 mentions this issue: cmd/compile: always write fun[0] in incompelte itab