Closed
Description
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)
}
Metadata
Metadata
Assignees
Labels
Type
Projects
Relationships
Development
No branches or pull requests
Participants
Activity
andybons commentedon Apr 4, 2019
github.com/abner-xu/gincmsdoes not appear to be available for inspection.Could you outline exact steps to reproduce the failure?
[-]listed multiple times[/-][+]cmd/compile: getting listed multiple times error[/+]andybons commentedon Apr 4, 2019
andybons commentedon Apr 4, 2019
abnerxc commentedon Apr 5, 2019
github.com/abner-xu/gincmsthis is directory in my local. I am usinggo modcreate projectandybons commentedon Apr 5, 2019
@Abner-Xu that repository isn't available publicly.
Please outline exact steps to take to recreate the problem.
abnerxc commentedon Apr 8, 2019
@andybons Please use this repositories
https://github.com/abner-xu/goweb.gitagnivade commentedon Apr 8, 2019
This seems to be a regression from 1.11. If the same type name is declared in multiple packages, it throws this error.
[-]cmd/compile: getting listed multiple times error[/-][+]cmd/compile: <autogenerated>:1: symbol listed multiple times for same type across multiple packages[/+]4 remaining items
randall77 commentedon Apr 10, 2019
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 commentedon Apr 11, 2019
Change https://golang.org/cl/171464 mentions this issue:
cmd/compile: use correct package name for stack object symbolrandall77 commentedon Apr 11, 2019
@gopherbot please open a backport to 1.11.
gopherbot commentedon Apr 11, 2019
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 commentedon Apr 11, 2019
@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()andCtxt.Lookup(fn.Func.lsym.Name + ".stkobj")?randall77 commentedon Apr 11, 2019
@gopherbot please open a backport to 1.12.
randall77 commentedon Apr 11, 2019
@cuonglm Yes, it's pretty cryptic.
fn.funcname()is just the function name (without the package) andlookupfinds that name in the current package being compiled.fn.Func.lsym.Nameis 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 commentedon Apr 12, 2019
@randall77 sorry, you'll have to open a backport bug for 1.12 yourself (if you haven't already). This is a known bug.
cmd/compile: clarify the difference between types.Sym and obj.LSym