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

gccgo: confusing closure names #29690

cherrymui opened this issue Jan 11, 2019 · 1 comment

gccgo: confusing closure names #29690

cherrymui opened this issue Jan 11, 2019 · 1 comment


Copy link

@cherrymui cherrymui commented Jan 11, 2019

What version of Go are you using (go version)?

gccgo2 (GCC) 9.0.0 20190108 (experimental)

What operating system and processor architecture are you using (go env)?


What did you do?

package main

type T struct {
	closure1, closure2 func()

func (t *T) M1()  { t.closure1 = func() { t.closure2() } }
func (t *T) M2()  { t.closure2 = func() { panic("XXX") } }

func main() {
	var t T

Built with gccgo, this program prints

panic: XXX

goroutine 1 [running]:

The closures on line 7 and 8 are different functions, yet have the same name, which is confusing. It is ok that closures have somewhat artificial names, but it is super confusing if different closures have the name.

It appears to me (without checking the source code) that if the closures are defined in global scope or inside a function (NOT method), they are properly named as package_name.funcN or package_name.function_name.funcN with proper N. However, if they are defined in methods, they are all named package_name.funcN with N starting from 1 in each method. In this case, the two closures are defined in two different methods, and both named main.func1.

cc @ianlancetaylor @thanm

@gopherbot gopherbot added this to the Gccgo milestone Jan 11, 2019
Copy link

@ianlancetaylor ianlancetaylor commented Jan 11, 2019

The symbols do have different names in the object file: main..1main.T.M1..func1 and main..1main.T.M2..func1. (These names are set by Gogo::nested_function_name in But the names in the debug info are indeed both main.func1. I think the confusion is happening in Named_object::get_id; I think that does an unfortunate munging of the full names.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants