Description
% cat x.go
package main
func f(x int) func() {
return func() {
panic(x)
}
}
func main() {
f(1)()
}
% go run -gcflags=-l x.go
panic: 1
goroutine 1 [running]:
main.f.func1()
/private/tmp/x.go:5 +0x26
main.main()
/private/tmp/x.go:10 +0x22
exit status 2
% go run x.go
panic: 1
goroutine 1 [running]:
main.main.func1(...)
/private/tmp/x.go:5
main.main()
/private/tmp/x.go:10 +0x28
exit status 2
%
Without inlining, the stack shows main.f.func1 panicking, which is approximately correct: it's the 1st closure inside main.f.
With inlining, the stack instead shows main.main.func1, because now it's the 1st closure inside main.main due to inlining of f. However, that's a much less useful name, since the closure is still lexically inside main.f. If there is some way to preserve the old name even when inlining, that would be a good idea.
This is the source of a Kubernetes test failure using Go 1.21, because a more complicated function was not being inlined in Go 1.20 but is being inlined in Go 1.21 after CL 492017. The test expected to see "newHandler" on the stack when a closure lexically inside newHandler panicked.
If there's something we can do here, we probably should, both to keep the closure names helpful and to keep tests like the Kubernetes one passing.
Metadata
Metadata
Assignees
Labels
Type
Projects
Status