cmd/compile: <autogenerated>:1: symbol listed multiple times for same type across multiple packages

[abnerxc]

Different packages and same struct function compile error

env

go version go1.12.1 windows/amd64

description

this problem happeded in version go1.12, my test in version go1.11 is ok. I think this is compile bug.
this file struct is very common in WEB MVC mode.

error

# github.com/abner-xu/gincms/router
duplicate "".(*IndexController).Index-fm.stkobj
<autogenerated>:1: symbol "".(*IndexController).Index-fm.stkobj listed multiple times

dirTree

code

main

func main() {
	router.RouterInit()
}

router

type HandlerFunc func(*string)

func RouterInit() {
	homeIndex := &home.IndexController{}
	GET(homeIndex.Index)
	adminIndex := &admin.IndexController{}
	GET(adminIndex.Index)
}
func GET(handlers ...HandlerFunc) {
	return
}

admin-IndexController

package admin

import "fmt"

type IndexController struct{}

func (this *IndexController) Index(m *string) {
	fmt.Println(&m)
}

home-IndexController

package home

import "fmt"

type IndexController struct{}

func (this *IndexController) Index(m *string) {
	fmt.Println(&m)
}

[andybons]

github.com/abner-xu/gincms does not appear to be available for inspection.

Could you outline exact steps to reproduce the failure?

[abnerxc]

github.com/abner-xu/gincms this is directory in my local. I am using go mod create project

[andybons]

@Abner-Xu that repository isn't available publicly.

Please outline exact steps to take to recreate the problem.

[abnerxc]

@andybons Please use this repositories https://github.com/abner-xu/goweb.git

[agnivade]

This seems to be a regression from 1.11. If the same type name is declared in multiple packages, it throws this error.

[agnivade]

@bcmills @jayconrod

[cuonglm]

git bisect points to 13baf4b

@randall77 If I added go:uintptrescapes pragma in one of IndexController method, the program can be compiled.

But if disable inlining via go tool compile -l, the problem still occurs. Any idea?

[randall77]

I have a fix.
The problem is the stack object generation code was always using the local package name for its symbol. Normally that doesn't matter, as we're only compiling functions in the local package. But for wrappers, the compiler generates functions which live in other packages. When there are two other packages with identical functions to wrap, the same name appears twice, and the compiler goes boom.

[gopherbot]

Change https://golang.org/cl/171464 mentions this issue: cmd/compile: use correct package name for stack object symbol

[randall77]

@gopherbot please open a backport to 1.11.

[gopherbot]

Backport issue(s) opened: #31396 (for 1.11).

Remember to create the cherry-pick CL(s) as soon as the patch is submitted to master, according to https://golang.org/wiki/MinorReleases.

[cuonglm]

@randall77 👍

Two places in CL are where I found when trying to fix this, but it's not clear to me what the different between lookup(fmt.Sprintf("%s.stkobj", fn.funcname())).Linksym() and Ctxt.Lookup(fn.Func.lsym.Name + ".stkobj")?

[randall77]

@gopherbot please open a backport to 1.12.

[randall77]

@cuonglm Yes, it's pretty cryptic. fn.funcname() is just the function name (without the package) and lookup finds that name in the current package being compiled. fn.Func.lsym.Name is the full name with package included.

This part of the compiler really needs better documentation. It confuses me every time I look at it also...

[andybons]

@randall77 sorry, you'll have to open a backport bug for 1.12 yourself (if you haven't already). This is a known bug.