-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
Comments
Why? What's the use case for it if it only has one stable option? |
Stabilizing |
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. |
|
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
The text was updated successfully, but these errors were encountered: