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

Jump to bottom

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

Closed
abnerxc opened this issue Apr 4, 2019 · 17 comments
Closed

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

abnerxc opened this issue Apr 4, 2019 · 17 comments
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone
Go1.13

Comments

@abnerxc
Copy link

abnerxc commented Apr 4, 2019

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

img

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
Copy link
Member

andybons commented Apr 4, 2019

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

Could you outline exact steps to reproduce the failure?

@andybons andybons added the WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided. label Apr 4, 2019
@andybons andybons added this to the Unplanned milestone Apr 4, 2019
@andybons andybons changed the title listed multiple times cmd/compile: getting listed multiple times error Apr 4, 2019
@andybons

This comment has been minimized.

Sign in to view
@andybons andybons closed this as completed Apr 4, 2019
@andybons

This comment has been minimized.

Sign in to view
@andybons andybons reopened this Apr 4, 2019
@abnerxc
Copy link
Author

abnerxc commented Apr 5, 2019

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

@andybons
Copy link
Member

andybons commented Apr 5, 2019

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

Please outline exact steps to take to recreate the problem.

@abnerxc
Copy link
Author

abnerxc commented Apr 8, 2019

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

@agnivade agnivade added NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. and removed WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided. labels Apr 8, 2019
@agnivade
Copy link
Contributor

agnivade commented 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.

@agnivade agnivade changed the title cmd/compile: getting listed multiple times error cmd/compile: <autogenerated>:1: symbol listed multiple times for same type across multiple packages Apr 8, 2019
@agnivade agnivade modified the milestones: Unplanned, Go1.13 Apr 8, 2019
@agnivade
Copy link
Contributor

agnivade commented Apr 8, 2019

@bcmills @jayconrod

@cuonglm
Copy link
Member

cuonglm commented Apr 10, 2019

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
Copy link
Contributor

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
Copy link

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

@randall77
Copy link
Contributor

@gopherbot please open a backport to 1.11.

@gopherbot
Copy link

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.

@gopherbot gopherbot mentioned this issue Apr 11, 2019
Closed
@cuonglm
Copy link
Member

cuonglm commented Apr 11, 2019 •
edited

@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
Copy link
Contributor

@gopherbot please open a backport to 1.12.

@randall77
Copy link
Contributor

@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
Copy link
Member

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

gopherbot pushed a commit that referenced this issue May 21, 2019
@cuonglm @randall77
cmd/compile: clarify the difference between types.Sym and obj.LSym
2d7cb29 
Both types.Sym and obj.LSym have the field Name, and that field is
widely used in compiler source. It can lead to confusion that when to
use which one.

So, adding documentation for clarifying the difference between them,
eliminate the confusion, or at least, make the code which use them
clearer for the reader.

See #31252 (comment)

Change-Id: I31f7fc6e4de4cf68f67ab2e3a385a7f451c796f5
Reviewed-on: https://go-review.googlesource.com/c/go/+/175019
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
@golang golang locked and limited conversation to collaborators Apr 21, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Milestone
Go1.13
Development

No branches or pull requests
6 participants
@andybons @agnivade @abnerxc @cuonglm @randall77 @gopherbot