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

cmd/compile: vargen numbering collisions #43633

Closed
mdempsky opened this issue Jan 11, 2021 · 3 comments
Closed

cmd/compile: vargen numbering collisions #43633

mdempsky opened this issue Jan 11, 2021 · 3 comments
Assignees
Labels
Milestone

Comments

@mdempsky
Copy link
Member

@mdempsky mdempsky commented Jan 11, 2021

This program is valid and the sub package successfully compiles, but then fails at import: https://play.golang.org/p/sGmXu0Bix_W

This is because we reset vargen numbering at function literals, so the two x variables both get exported with the same name. We should probably just get rid of vargen for ONAMEs. We can disambiguate by the Names directly.

/cc @danscales

@mdempsky mdempsky added this to the Go1.17 milestone Jan 11, 2021
@mdempsky mdempsky self-assigned this Jan 11, 2021
@gopherbot
Copy link

@gopherbot gopherbot commented Jan 12, 2021

Change https://golang.org/cl/283192 mentions this issue: [dev.regabi] cmd/compile: decouple escape analysis from Name.Vargen

Loading

@gopherbot
Copy link

@gopherbot gopherbot commented Jan 12, 2021

Change https://golang.org/cl/283193 mentions this issue: [dev.regabi] cmd/compile: stop using Vargen for import/export

Loading

gopherbot pushed a commit that referenced this issue Jan 12, 2021
Escape analysis needs to know the index of result parameters for
recording escape-flow information. It currently relies on Vargen for
this, but it can easily figure this out for itself. So just do that
instead, so that we can remove Vargen.

Passes toolstash -cmp.

For #43633.

Change-Id: I65dedc2d73bc25e85ff400f308e50b73dc503630
Reviewed-on: https://go-review.googlesource.com/c/go/+/283192
Trust: Matthew Dempsky <mdempsky@google.com>
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dan Scales <danscales@google.com>
gopherbot pushed a commit that referenced this issue Jan 12, 2021
Historically, inline function bodies were exported as plain Go source
code, and symbol mangling was a convenient hack because it allowed
variables to be re-imported with largely the same names as they were
originally exported as.

However, nowadays we use a binary format that's more easily extended,
so we can simply serialize all of a function's declared objects up
front, and then refer to them by index later on. This also allows us
to easily report unmangled names all the time (e.g., error message
from issue7921.go).

Fixes #43633.

Change-Id: I46c88f5a47cb921f70ab140976ba9ddce38df216
Reviewed-on: https://go-review.googlesource.com/c/go/+/283193
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dan Scales <danscales@google.com>
Trust: Dan Scales <danscales@google.com>
Trust: Matthew Dempsky <mdempsky@google.com>
@mdempsky
Copy link
Member Author

@mdempsky mdempsky commented Jan 18, 2021

This is fixed on dev.regabi.

Loading

@mdempsky mdempsky closed this Jan 18, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants