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

runtime: wrong type assertion result when using generic types #51700

Closed
disksing opened this issue Mar 16, 2022 · 8 comments
Closed

runtime: wrong type assertion result when using generic types #51700

disksing opened this issue Mar 16, 2022 · 8 comments
Labels
NeedsFix release-blocker
Milestone

Comments

@disksing
Copy link

@disksing disksing commented Mar 16, 2022

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

@griesemer griesemer commented Mar 16, 2022

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

@mdempsky mdempsky commented Mar 16, 2022

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

@heschi heschi added the NeedsFix label Mar 16, 2022
@heschi heschi added this to the Go1.19 milestone Mar 16, 2022
@heschi
Copy link
Contributor

@heschi heschi commented Mar 16, 2022

Tentatively marking release blocker.

@mdempsky
Copy link
Member

@mdempsky mdempsky commented Mar 16, 2022

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

@mdempsky
Copy link
Member

@mdempsky mdempsky commented Mar 16, 2022

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

@ianlancetaylor ianlancetaylor commented Mar 17, 2022

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

@gopherbot gopherbot commented Mar 17, 2022

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.

@dmitshur dmitshur changed the title go/runtime: wrong type assertion result when using generic types runtime: wrong type assertion result when using generic types Apr 6, 2022
@gopherbot
Copy link

@gopherbot gopherbot commented Apr 8, 2022

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
NeedsFix release-blocker
Projects
None yet
Development

No branches or pull requests

6 participants