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

Stabilize -Zsymbol-mangling-version / RFC2603? #77116

Closed
jsgf opened this issue Sep 23, 2020 · 4 comments
Closed

Stabilize -Zsymbol-mangling-version / RFC2603? #77116

jsgf opened this issue Sep 23, 2020 · 4 comments
Labels
T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@jsgf
Copy link
Contributor

jsgf commented Sep 23, 2020

Where are we with stabilizing RFC2603 and the -Zsymbol-mangling-version? Can we introduce -Csymbol-mangling-version?

(Note, I'm not thinking about changing the default from legacy yet, but we can also discuss that.)

cc @eddyb @michaelwoerister

@tesuji
Copy link
Contributor

tesuji commented Sep 23, 2020

Why? What's the use case for it if it only has one stable option?

@jonas-schievink
Copy link
Contributor

Stabilizing -Csymbol-mangling-version would imply stabilizing both the RFC 2603 mangling as well as the currently used legacy mangling, which does not seem like a good idea to me.

@jsgf
Copy link
Contributor Author

jsgf commented Sep 24, 2020

I guess that's a question of what it means for the mangling to be "stable". Since Rust has no ABI guarantees, there's nothing in principle preventing either mangling scheme from changing from release to release. But since it's also an interface to other tools they need to be managed in a somewhat sensible way.

Legacy mangling gets away with this because it looks enough like typical C++ mangling for tools to show something useful (to a greater or lesser extent).

"v0" mangling needs more tool support to get good results, so there's a question of how well that support has been propagated (eg gdb and binutils has support for it upstream now, I think, but I don't know about current state of other tooling). Also if we extend v0 mangling to support new language features, will those demanglers degrade gracefully? (AFAIK @eddyb implemented them all, so I'm reasonably sure they will have taken that into consideration.)

So I think there's probably quite a few users which are currently relying on "legacy" as part of their environment, and have been for some time, so in that sense it is "stable". But we've been using "v0" for its richer type info for 1 year+, but its awkward that we need to invoke rustc in a nightly-like way to get it.

I'm also concerned that people are overlooking v0 mangling with the potential to introduce bugs, so we need to make sure its on equal footing with respect to regression testing etc.

So from my POV it makes sense to stabilize the option but retain the existing behaviour, until we're in the position to flip the default.

I think the counterargument would be that v0 mangling has some clear flaw and will need to be revised, in which case we should do a v1 and stabilize that. But I haven't seen anything to that effect. v0 - being a lot more inforation rich - is also a lot larger, but I don't know how much of a concern that is in practice.

@LeSeulArtichaut LeSeulArtichaut added the T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. label Sep 25, 2020
@tmiasko
Copy link
Contributor

tmiasko commented Jan 14, 2022

-C symbol-mangling-version=v0 was stabilized in #90128.

@tmiasko tmiasko closed this as completed Jan 14, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

5 participants