cmd/compile: cleanup the extra "func" in closure name

[cuonglm]

Coming here from https://go-review.googlesource.com/c/go/+/437216/2..3/test/closure3.dir/main.go#b255.

Currently, the compiler names the closures base on the outer function:

package main

func main() {
	a := 2
	if r := func(x int) int {
		b := 3
		return func(y int) int {
			c := 5
			return func(z int) int {
				return a*x + b*y + c*z
			}(10)
		}(100)
	}(1000); r != 2350 {
		panic("r != 2350")
	}
}

For:

return func(z int) int {
	return a*x + b*y + c*z
}(10)

Unified IR generates main.func1.func2, while the old frontend generates main.func1.2. The discrepancy happens when calling ir.NameClosure. The old frontend use the immediate outer function (return func(y int) int { ... }) as outer function, while Unified IR use the outer most (func main() { ... }).

@mdempsky think that the func prefix may not be necessary, and we can remove it.

[thediveo]

If I'm not mistaken then the IR names generation might break goroutine leak checkers, such as https://github.com/uber-go/goleak and gleak from https://github.com/onsi/gomega; these today use filter lists of function names to filter out known "good" go routines.

[mdempsky]

@thediveo Thanks, that's an interesting use case to keep in mind.

[mdempsky]

Note that even today we're inconsistent about naming of function literals when inlining is enabled.

Here's an example where the same function literal is assigned 3 different names due to to inlining: https://go.dev/play/p/_nvmEZGSmRb