cmd/gc: name closure for outer function

[gopherbot]

by Matthew.Horsnell:

What does 'go version' print?
go version go1.3 linux/amd64

What steps reproduce the problem?

Profile any code with closures in it.

What happened?

The profile information contains non-specific function names for closures i.e.
<package>.func.<%03d>.

What should have happened instead?

Ideally it would be nice to at least know where the closure was generated in the package
i.e. <package>.<closure generating func>.func.<%03d>

[ianlancetaylor]

Comment 1:

Labels changed: added repo-main, release-go1.4.

[gopherbot]

Comment 2 by Matthew.Horsnell:

As an additional, obvious, note. The anonymous functions can not be viewed from list in
go tool pprof either.

[gopherbot]

Comment 3 by Matthew.Horsnell:

example profile:
Welcome to pprof!  For help, type 'help'.
(pprof) top20 -cum
Total: 785 samples
       0   0.0%   0.0%      785 100.0% main.main
      61   7.8%   7.8%      785 100.0% main.test
       0   0.0%   7.8%      785 100.0% runtime.gosched0
       0   0.0%   7.8%      785 100.0% runtime.main
      16   2.0%   9.8%      509  64.8% github.com/repo/funcA
     391  49.8%  59.6%      493  62.8% github.com/repo/funcB
      25   3.2%  62.8%      159  20.3% math/rand.(*Rand).Uint32
      43   5.5%  68.3%      134  17.1% math/rand.(*Rand).Int63
      91  11.6%  79.9%       91  11.6% math/rand.(*rngSource).Int63
      23   2.9%  82.8%       23   2.9% github.com/repo/funcC
       6   0.8%  83.6%       20   2.5% github.com/repo/package.funcD
       4   0.5%  84.1%       20   2.5% github.com/repo/package.func·016
      11   1.4%  85.5%       15   1.9% github.com/repo/package.func·003
       6   0.8%  86.2%       14   1.8% github.com/repo/package.func·029
       7   0.9%  87.1%       14   1.8% runtime.mapaccess2_faststr
      12   1.5%  88.7%       13   1.7% github.com/repo/package.func·001
      11   1.4%  90.1%       13   1.7% github.com/repo/package.func·005
      12   1.5%  91.6%       13   1.7% github.com/repo/package.func·030
       5   0.6%  92.2%        8   1.0% github.com/repo/package.func·013
       5   0.6%  92.9%        8   1.0% github.com/repo/package.func·017

[gopherbot]

Comment 4 by Matthew.Horsnell:

example call to list closure:
(pprof) list package.func·005         
Total: 785 samples
(pprof)

[rsc]

Comment 5:

I think the pprof problem is a Perl Unicode issue. The new pprof written in Go will not
have this problem.

Status changed to Accepted.

[rsc]

Comment 6:

I looked into this but it's a little tricky. Leaving for Go 1.5.

Labels changed: added release-go1.5, removed release-go1.4.

[rsc]

Comment 7:

Issue #8943 has been merged into this issue.

[adonovan]

Comment 8:

I agree this change would help readers of the output of various static and dynamic
analyses.
May I humbly suggest following the naming convention used by the SSA builder?
f$1 for the first function literal within function f.
f$1$2 for the second function literal within f$1, etc.
init$1 for the first function literal among the package's variable initializer
expressions.
init#1 for the first declared init function in the package.
etc.

[rsc]

Comment 9:

There's no need for $ and #. A simple . will work just fine.

[adonovan]

Comment 10:

> There's no need for $ and #. A simple . will work just fine.
Ok, one of them could be replaced by a dot, and I'll make go/ssa consistent with
whatever you ultimately go with, but you want to distinguish "the first declared init
function" from "the first lambda in a variable initializer", don't you?

[rsc]

Comment 11:

I'll probably just keep calling the top-level closures func.1 func.2, etc.