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

cmd/compile: bad handling of closures in generic body #45738

Closed
randall77 opened this issue Apr 23, 2021 · 2 comments
Closed

cmd/compile: bad handling of closures in generic body #45738

randall77 opened this issue Apr 23, 2021 · 2 comments
Labels
FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done.
Milestone

Comments

@randall77
Copy link
Contributor

package main

//go:noinline
func f[T any]() {
	x := 5
	g := func() int { return x }
	g()
}

func main() {
	f[int]()
}

generates

$ go tool compile -G=3 tmp.go
panic: interface conversion: interface {} is nil, not *escape.location
goroutine 1 [running]:
cmd/compile/internal/escape.(*batch).oldLoc(...)
	/Users/khr/sandbox/ro/src/cmd/compile/internal/escape/escape.go:1311

A small debugging print in (*batch).oldLoc at that line number indicates the variable without a location is ~r0.

There's nothing directly related to generics going on here, just something I suspect triggered by the slightly different phase ordering when processing generic functions.

@dancsales

@randall77
Copy link
Contributor Author

This appears to be because we're not copying the formal parameters of a closure. When we copy a closure, we're not making new formal parameters for the closure because its type doesn't have any generic parameters. But we do make a copy of the formal parameter when we encounter it in the body of the closure. Escape analysis treats these two Names as different, and one of them was never assigned a location.
I think we need to copy the type of the closure always, even when it doesn't have any type parameters. it's not that simple though, or I would have fixed it already :(. Still looking.

@cherrymui cherrymui added the NeedsFix The path to resolution is known, but the work has not been done. label Apr 26, 2021
@cherrymui cherrymui added this to the Go1.18 milestone Apr 26, 2021
@gopherbot
Copy link

Change https://golang.org/cl/313652 mentions this issue: cmd/compile: fix nongeneric closures in generic functions

@golang golang locked and limited conversation to collaborators Apr 27, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done.
Projects
None yet
Development

No branches or pull requests

3 participants