Only emit forward compatible v0 symbol names with graceful degradation

[michaelwoerister]

Proposal

The long time it takes for downstream tooling like GDB, perf, or valgrind to pick up support for changes in the v0 symbol mangling grammar has been the only real reason why v0 mangling is not the standard yet. This is not the fault of these tools, but rather a side effect of long-lived Linux distros sticking to a particular version of these tools for many years. This MCP proposes to mitigate the problem by using the existing v0 grammar in a way that allows graceful degradation:

• The compiler commits to only emitting symbol names that are valid according to the current version of the v0 grammar, so that demanglers as currently implemented in existing tools can always demangle them (at least partially).
• Any additions to the grammar (in particular those planned for more complex const generics) will be wrapped in a special C<decimal number>_<mangled contents> production, where the decimal is the number of bytes in <mangled contents> plus the _. <mangled contents> is a v0 fragment containing newer grammar elements. To a current demangler, this will look like a regular crate-root production and it will demangle it as if _<mangled contents> was an identifier. This works because the identifier production can contain arbitrary content and the decimal prefix allows it to skip ahead.
• Newer versions of demanglers will know about the special meaning of the C<decimal number>_ prefix. If they encounter it, they will try to demangle the contents. If that succeeds, great! If not, they can print the contents verbatim or some kind of placeholder.

The overall effect is that of graceful degradation. Old demanglers will show a mostly correct name, except for the generic parameters or types they don't understand.

Example

The symbol name my_crate::foo<{ (1i64, 2i64, 3i64) }> is mangled to _RINxC8my_crate3fooKTx1_x2_x3_EE according to the const generics additions proposed in rust-lang/rfcs#3161. Current demanglers will just fail to demangle this.

With the mitigation, it would be mangled to _RINxC8my_crate3fooC13_KTx1_x2_x3_EE (notice the added C13_ before the generic parameter). A current demangler will demangle this as my_crate::foo<_KTx1_x2_x3_E>. A newer demangler will be able to fully reconstruct the original my_crate::foo<{ (1i64, 2i64, 3i64) }>.

I expect that for complex symbol names with deeply nested generic arguments, getting a best effort demangling is a welcome improvement over just the mangled name.

The proposed solution is one possibility (inspired by @eddyb's proposol for dealing with f16 in rust-lang/rust#122106 (comment)). I'd be happy to hear other ideas.

Mentors or Reviewers

None yet.

Process

The main points of the Major Change Process are as follows:

• File an issue describing the proposal.
• A compiler team member or contributor who is knowledgeable in the area can second by writing @rustbot second.
  • Finding a "second" suffices for internal changes. If however, you are proposing a new public-facing feature, such as a -C flag, then full team check-off is required.
  • Compiler team members can initiate a check-off via @rfcbot fcp merge on either the MCP or the PR.
• Once an MCP is seconded, the Final Comment Period begins. If no objections are raised after 10 days, the MCP is considered approved.

You can read more about Major Change Proposals on forge.

Comments

This issue is not meant to be used for technical discussion. There is a Zulip stream for that. Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.

[rustbot]

This issue is not meant to be used for technical discussion. There is a Zulip stream for that. Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.

Concerns or objections to the proposal should be discussed on Zulip and formally registered here by adding a comment with the following syntax:

@rustbot concern reason-for-concern 
<description of the concern> 

Concerns can be lifted with:

@rustbot resolve reason-for-concern 

See documentation at https://forge.rust-lang.org

cc @rust-lang/compiler @rust-lang/compiler-contributors

[michaelwoerister]

We discussed this in the design meeting on Jun 14 and decided to not pursue this approach any further. Instead we'll document the policy that breaking changes can occur due to addition to the grammar (which are usually necessary only for some new language features).