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

Jump to bottom

cmd/compile: another "unreachable method called" bug #49049

Closed
randall77 opened this issue Oct 18, 2021 · 4 comments
Closed

cmd/compile: another "unreachable method called" bug #49049

randall77 opened this issue Oct 18, 2021 · 4 comments
Labels
FrozenDueToAge generics Issue is related to generics NeedsFix The path to resolution is known, but the work has not been done. release-blocker
Milestone
Go1.18

Comments

@randall77
Copy link
Contributor

Another case where we're not marking methods as used correctly.

package main

type A[T any] interface {
	m()
}

type Z struct {
	a,b int
}

func (z *Z) m() {
}

func test[T any]() {
	var a A[T] = &Z{}
	f := a.m
	f()
}
func main() {
	test[string]()
}

$ go run ~/gowork/tmp1.go
fatal error: unreachable method called. linker bug?

goroutine 1 [running]:
runtime.throw({0x1063317, 0x100ac07})
	/Users/khr/sandbox/ro3/src/runtime/panic.go:965 +0x71 fp=0xc000052710 sp=0xc0000526e0 pc=0x102aa91
runtime.unreachableMethod()
	/Users/khr/sandbox/ro3/src/runtime/iface.go:525 +0x25 fp=0xc000052730 sp=0xc000052710 pc=0x1008925
main.A[...].m-fm()
	/Users/khr/gowork/tmp1.go:4 +0x2b fp=0xc000052748 sp=0xc000052730 pc=0x1053bab
main.test[...](...)
	/Users/khr/gowork/tmp1.go:16
main.main()
	/Users/khr/gowork/tmp1.go:19 +0x5f fp=0xc000052780 sp=0xc000052748 pc=0x1053b5f
runtime.main()
	/Users/khr/sandbox/ro3/src/runtime/proc.go:255 +0x227 fp=0xc0000527e0 sp=0xc000052780 pc=0x102d1a7
runtime.goexit()
	/Users/khr/sandbox/ro3/src/runtime/asm_amd64.s:1446 +0x1 fp=0xc0000527e8 sp=0xc0000527e0 pc=0x1050e81

@danscales @cherrymui
@randall77 randall77 added release-blocker generics Issue is related to generics labels Oct 18, 2021
@randall77 randall77 added this to the Go1.18 milestone Oct 18, 2021
@cherrymui cherrymui added the NeedsFix The path to resolution is known, but the work has not been done. label Oct 18, 2021
@randall77
Copy link
Contributor Author

@danscales
I don't think this is directly a unreachable code bug. I think it is deeper than that, and the error we get is just a late symptom.

The problem is that we need to make a closure for a.m at line 16. To do that, we look for OMETHVALUE early in stenciling. But at that point, a.m is still an OXDOT. So we don't transform it into a closure, but just leave it alone. Stenciling eventually calls transform on the OXDOT and makes it a OMETHVALUE, but by then it is too late.
Maybe we could make it a closure at that point? But I think maybe we want the transform to happen before stenciling in this case. We don't need to know anything about T to know it is an OMETHVALUE earlier, as A is a known interface even without knowing T.

@danscales
Copy link
Contributor

@randall77

We transform the METHVALUE to a closure (in order to include the dictionary arg) in the "modify" pass, after stenciling. So, the METHVALUE is available at the right time (after stenciling, hence right before the modify pass), but the reason why we are not setting "closureRequired" is because a is an interface (see IsInterfaceMethod() check in same line checking for OMETHVALUE around line 156 in stencil.go). Since a is already an interface, we don't need to do the closure, right? We just get the function from the itab (which will be a generic wrapper that includes the dictionary).

Maybe I'm missing something, but it seems like this is another example of a parameterized interface confusing the linker dead-code elimination (but in a slightly different way?)

@randall77
Copy link
Contributor Author

Yes, you're right, we don't actually need a closure because the thing in the itab entry already closes over the required dictionary. Ok, back to my first take on this, just another unreachable code issue.

@gopherbot
Copy link

Change https://golang.org/cl/357835 mentions this issue: cmd/compile,cmd/link: introduce generic interface call relocations

@golang golang locked and limited conversation to collaborators Oct 25, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge generics Issue is related to generics NeedsFix The path to resolution is known, but the work has not been done. release-blocker
Projects
None yet
Milestone
Go1.18
Development

No branches or pull requests
4 participants
@danscales @randall77 @gopherbot @cherrymui