switch to v0 mangling by default on stable by davidtwco · Pull Request #151994 · rust-lang/rust

davidtwco · 2026-02-02T12:38:03Z

Following #89117, rustc has defaulted to the v0 mangling scheme by default (since Nov 20th 2025). This surfaced two bugs:

ICE: coverage: symbol_names: unexpected DefPathData: GlobalAsm #138261 was a small ICE (found via fuzzing) where an implementation-internal namespace was missing for global assembly - this occurs with names instantiated within global assembly (that can happen inside constants)
ICE: impossible case reached wit gce + v0 symbol mangling #134479 only occurs with unstable generic_const_exprs

Since there have been three-to-four months for users to find bugs with this mangling scheme on nightly, that the scheme has been waiting many years to be stabilised, and has been used successfully internally at Microsoft, Meta and Google for many years, this patch proposes stabilising the v0 mangling scheme on stable.

This patch does not propose removing the legacy mangling, it will remain usable on nightly as an escape-hatch if there are remaining bugs (though admittedly it would require switching to nightly for those on stable) - it is anticipated that this would be unlikely given current testing undergone by v0. Legacy mangling can be removed in another follow-up.

r? @wesleywiser

Following rust-lang#89117, rustc has defaulted to the v0 mangling scheme by default (since Nov 20th 2025). This surfaced two bugs: - rust-lang#138261 was a small ICE (found via fuzzing) where an implementation-internal namespace was missing for global assembly - this occurs with names instantiated within global assembly (that can happen inside constants) - rust-lang#134479 only occurs with unstable `generic_const_exprs` Since there have been three-to-four months for users to find bugs with this mangling scheme on nightly, that the scheme has been waiting many years to be stabilised, and has been used successfully internally at Microsoft, Meta and Google for many years, this patch proposes stabilising the v0 mangling scheme on stable. This patch does not propose removing the legacy mangling, it will remain usable on nightly as an escape-hatch if there are remaining bugs (though admittedly it would require switching to nightly for those on stable) - it is anticipated that this would be unlikely given current testing undergone by v0. Legacy mangling can be removed in another follow-up.

rustbot · 2026-02-02T12:38:08Z

wesleywiser is currently at their maximum review capacity.
They may take a while to respond.

rustbot · 2026-02-02T12:38:09Z

⚠️ Warning ⚠️

There are issue links (such as #123) in the commit messages of the following commits.
Please move them to the PR description, to avoid spamming the issues with references to the commit, and so this bot can automatically canonicalize them to avoid issues with subtree.
- a4c0bf5

davidtwco · 2026-02-02T12:38:41Z

This will require an FCP and probably another blog post as a follow-up to the previous one.

Kobzol · 2026-02-02T13:05:10Z

Shouldn't -Csymbol-mangling-version=legacy be stabilized first, so that you can opt-out of v0, in case someone still needs the legacy mangling scheme?

wesleywiser · 2026-02-03T03:45:32Z

I would prefer that we do not stabilize -Csymbol-mangling-version=legacy so that the legacy symbol mangling scheme can be removed entirely.

wesleywiser · 2026-02-03T03:50:13Z

@rfcbot fcp merge compiler

rust-rfcbot · 2026-02-03T03:50:15Z

petrochenkov · 2026-02-03T11:50:22Z

It seems like #92316 (comment) was never addressed.
But it shouldn't be blocking now because extern types are unstable (it would still be good to open an issue to track and investigate it).

Noratrieb · 2026-02-03T18:22:48Z

I would prefer that we do not stabilize -Csymbol-mangling-version=legacy so that the legacy symbol mangling scheme can be removed entirely.

I think it would be reasonable to stabilize it with a deprecation warning when enabled (and still remove it in the future). I don't see a significant downside of this approach, with the big upside that people can opt-out on their normal stable toolchain.
But I do not know if this is something many people will actually need. But it also seems easy to implement.

hanna-kruppe · 2026-02-03T20:25:19Z

In particular, the very useful cargo llvm-lines tool doesn’t work properly with v0 mangling yet: dtolnay/cargo-llvm-lines#78

davidtwco · 2026-02-17T13:36:32Z

I think it would be reasonable to stabilize it with a deprecation warning when enabled (and still remove it in the future). I don't see a significant downside of this approach, with the big upside that people can opt-out on their normal stable toolchain. But I do not know if this is something many people will actually need. But it also seems easy to implement.

It would be easy to do, I'm not opposed to it, but if we find we don't need it stabilised at all then I think that would be marginally better.

davidtwco · 2026-02-17T13:39:03Z

It seems like #92316 (comment) was never addressed. But it shouldn't be blocking now because extern types are unstable (it would still be good to open an issue to track and investigate it).

I wasn't aware of this, added it to the extern type tracking issue: #43467

rust-rfcbot · 2026-03-12T03:42:35Z

🔔 This is now entering its final comment period, as per the review above. 🔔

petrochenkov · 2026-04-17T14:53:46Z

@rfcbot resolve late-anon-const

#143361 was effectively reverted in #153955, removing the new mangling symbol for "late anon consts".

rust-rfcbot · 2026-04-17T14:55:15Z

🔔 This is now entering its final comment period, as per the review above. 🔔

wesleywiser · 2026-04-28T14:22:06Z

@bors r+

rust-bors · 2026-04-28T14:22:10Z

📋 This PR cannot be approved because it currently has the following label: final-comment-period.

wesleywiser · 2026-04-28T14:26:12Z

@bors r+

rust-bors · 2026-04-28T14:26:15Z

📌 Commit a4c0bf5 has been approved by wesleywiser

It is now in the queue for this repository.

@wesleywiser

…=wesleywiser switch to v0 mangling by default on stable Following rust-lang#89117, rustc has defaulted to the v0 mangling scheme by default (since Nov 20th 2025). This surfaced two bugs: - rust-lang#138261 was a small ICE (found via fuzzing) where an implementation-internal namespace was missing for global assembly - this occurs with names instantiated within global assembly (that can happen inside constants) - rust-lang#134479 only occurs with unstable `generic_const_exprs` Since there have been three-to-four months for users to find bugs with this mangling scheme on nightly, that the scheme has been waiting many years to be stabilised, and has been used successfully internally at Microsoft, Meta and Google for many years, this patch proposes stabilising the v0 mangling scheme on stable. This patch does not propose removing the legacy mangling, it will remain usable on nightly as an escape-hatch if there are remaining bugs (though admittedly it would require switching to nightly for those on stable) - it is anticipated that this would be unlikely given current testing undergone by v0. Legacy mangling can be removed in another follow-up. r? @wesleywiser

@wesleywiser

…=wesleywiser switch to v0 mangling by default on stable Following rust-lang#89117, rustc has defaulted to the v0 mangling scheme by default (since Nov 20th 2025). This surfaced two bugs: - rust-lang#138261 was a small ICE (found via fuzzing) where an implementation-internal namespace was missing for global assembly - this occurs with names instantiated within global assembly (that can happen inside constants) - rust-lang#134479 only occurs with unstable `generic_const_exprs` Since there have been three-to-four months for users to find bugs with this mangling scheme on nightly, that the scheme has been waiting many years to be stabilised, and has been used successfully internally at Microsoft, Meta and Google for many years, this patch proposes stabilising the v0 mangling scheme on stable. This patch does not propose removing the legacy mangling, it will remain usable on nightly as an escape-hatch if there are remaining bugs (though admittedly it would require switching to nightly for those on stable) - it is anticipated that this would be unlikely given current testing undergone by v0. Legacy mangling can be removed in another follow-up. r? @wesleywiser

@wesleywiser

…=wesleywiser switch to v0 mangling by default on stable Following rust-lang#89117, rustc has defaulted to the v0 mangling scheme by default (since Nov 20th 2025). This surfaced two bugs: - rust-lang#138261 was a small ICE (found via fuzzing) where an implementation-internal namespace was missing for global assembly - this occurs with names instantiated within global assembly (that can happen inside constants) - rust-lang#134479 only occurs with unstable `generic_const_exprs` Since there have been three-to-four months for users to find bugs with this mangling scheme on nightly, that the scheme has been waiting many years to be stabilised, and has been used successfully internally at Microsoft, Meta and Google for many years, this patch proposes stabilising the v0 mangling scheme on stable. This patch does not propose removing the legacy mangling, it will remain usable on nightly as an escape-hatch if there are remaining bugs (though admittedly it would require switching to nightly for those on stable) - it is anticipated that this would be unlikely given current testing undergone by v0. Legacy mangling can be removed in another follow-up. r? @wesleywiser

…uwer Rollup of 12 pull requests Successful merges: - #151994 (switch to v0 mangling by default on stable) - #154325 (Tweak irrefutable let else warning output) - #155899 (`dlltool`: Set the working directory to workaround `--temp-prefix` bug) - #155273 (Lock stable_crate_ids once in create_crate_num) - #155361 (Document that CFI diverges from Rust wrt. ABI-compatibility rules) - #155692 (disable naked-dead-code-elimination test if no RET mnemonic is available) - #155747 (Update documentation for `wasm32-wali-linux-musl` after integrating n…) - #155768 (compiletest: Overhaul the code for running an incremental test revision) - #155907 (Handle hkl const closures) - #155910 (misc stuff from reading borrowck again :)) - #155913 (Delete the 12 year old fixme) - #155920 (remove review queue triagebot mentions)

@wesleywiser

…=wesleywiser switch to v0 mangling by default on stable Following rust-lang#89117, rustc has defaulted to the v0 mangling scheme by default (since Nov 20th 2025). This surfaced two bugs: - rust-lang#138261 was a small ICE (found via fuzzing) where an implementation-internal namespace was missing for global assembly - this occurs with names instantiated within global assembly (that can happen inside constants) - rust-lang#134479 only occurs with unstable `generic_const_exprs` Since there have been three-to-four months for users to find bugs with this mangling scheme on nightly, that the scheme has been waiting many years to be stabilised, and has been used successfully internally at Microsoft, Meta and Google for many years, this patch proposes stabilising the v0 mangling scheme on stable. This patch does not propose removing the legacy mangling, it will remain usable on nightly as an escape-hatch if there are remaining bugs (though admittedly it would require switching to nightly for those on stable) - it is anticipated that this would be unlikely given current testing undergone by v0. Legacy mangling can be removed in another follow-up. r? @wesleywiser

…uwer Rollup of 14 pull requests Successful merges: - #155850 (Only exclude the #155473 change for 1-byte bool-likes) - #155923 (Subtree sync for rustc_codegen_cranelift) - #151994 (switch to v0 mangling by default on stable) - #154325 (Tweak irrefutable let else warning output) - #155899 (`dlltool`: Set the working directory to workaround `--temp-prefix` bug) - #155273 (Lock stable_crate_ids once in create_crate_num) - #155361 (Document that CFI diverges from Rust wrt. ABI-compatibility rules) - #155692 (disable naked-dead-code-elimination test if no RET mnemonic is available) - #155747 (Update documentation for `wasm32-wali-linux-musl` after integrating n…) - #155768 (compiletest: Overhaul the code for running an incremental test revision) - #155907 (Handle hkl const closures) - #155910 (misc stuff from reading borrowck again :)) - #155913 (Delete the 12 year old fixme) - #155920 (remove review queue triagebot mentions)

…uwer Rollup of 15 pull requests Successful merges: - #155923 (Subtree sync for rustc_codegen_cranelift) - #155930 (Sync from portable simd 2026 04 28) - #155850 (Only exclude the #155473 change for 1-byte bool-likes) - #151994 (switch to v0 mangling by default on stable) - #154325 (Tweak irrefutable let else warning output) - #155273 (Lock stable_crate_ids once in create_crate_num) - #155361 (Document that CFI diverges from Rust wrt. ABI-compatibility rules) - #155692 (disable naked-dead-code-elimination test if no RET mnemonic is available) - #155747 (Update documentation for `wasm32-wali-linux-musl` after integrating n…) - #155768 (compiletest: Overhaul the code for running an incremental test revision) - #155907 (Handle hkl const closures) - #155910 (misc stuff from reading borrowck again :)) - #155913 (Delete the 12 year old fixme) - #155920 (remove review queue triagebot mentions) - #155936 (Rename `SharedContext::emit_dyn_lint*` into `emit_lint*`)

@wesleywiser

Rollup merge of #151994 - davidtwco:v0-mangling-on-stable, r=wesleywiser switch to v0 mangling by default on stable Following #89117, rustc has defaulted to the v0 mangling scheme by default (since Nov 20th 2025). This surfaced two bugs: - #138261 was a small ICE (found via fuzzing) where an implementation-internal namespace was missing for global assembly - this occurs with names instantiated within global assembly (that can happen inside constants) - #134479 only occurs with unstable `generic_const_exprs` Since there have been three-to-four months for users to find bugs with this mangling scheme on nightly, that the scheme has been waiting many years to be stabilised, and has been used successfully internally at Microsoft, Meta and Google for many years, this patch proposes stabilising the v0 mangling scheme on stable. This patch does not propose removing the legacy mangling, it will remain usable on nightly as an escape-hatch if there are remaining bugs (though admittedly it would require switching to nightly for those on stable) - it is anticipated that this would be unlikely given current testing undergone by v0. Legacy mangling can be removed in another follow-up. r? @wesleywiser

davidtwco added T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. needs-fcp This change is insta-stable, or significant enough to need a team FCP to proceed. A-name-mangling Area: Name mangling / decoration aka symbol mangling labels Feb 2, 2026

rustbot assigned wesleywiser Feb 2, 2026

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) labels Feb 2, 2026

wesleywiser approved these changes Feb 3, 2026

View reviewed changes

This comment was marked as outdated.

Sign in to view

rust-rfcbot added proposed-final-comment-period Proposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off. disposition-merge This issue / PR is in PFCP or FCP with a disposition to merge it. labels Feb 3, 2026

rust-rfcbot added final-comment-period In the final comment period and will be merged soon unless new substantive objections are raised. and removed proposed-final-comment-period Proposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off. labels Mar 12, 2026

apiraino removed the to-announce Announce this issue on triage meeting label Apr 2, 2026

rust-rfcbot added final-comment-period In the final comment period and will be merged soon unless new substantive objections are raised. and removed proposed-final-comment-period Proposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off. labels Apr 17, 2026

wesleywiser approved these changes Apr 28, 2026

View reviewed changes

wesleywiser removed the final-comment-period In the final comment period and will be merged soon unless new substantive objections are raised. label Apr 28, 2026

rust-bors Bot added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Apr 28, 2026

JonathanBrouwer mentioned this pull request Apr 28, 2026

Rollup of 12 pull requests #155933

Closed

JonathanBrouwer mentioned this pull request Apr 28, 2026

Rollup of 14 pull requests #155937

Closed

JonathanBrouwer mentioned this pull request Apr 28, 2026

Rollup of 15 pull requests #155941

Merged

rust-bors Bot merged commit 1857d2e into rust-lang:main Apr 28, 2026
11 checks passed

rustbot added this to the 1.97.0 milestone Apr 28, 2026

davidtwco deleted the v0-mangling-on-stable branch April 28, 2026 22:48

XSpielinbox mentioned this pull request Apr 29, 2026

Add support for V0 mangling cackle-rs/cackle#44

Merged

Uh oh!

Conversation

davidtwco commented Feb 2, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rustbot commented Feb 2, 2026

Uh oh!

rustbot commented Feb 2, 2026

Uh oh!

davidtwco commented Feb 2, 2026

Uh oh!

Kobzol commented Feb 2, 2026

Uh oh!

wesleywiser commented Feb 3, 2026

Uh oh!

This comment was marked as outdated.

This comment was marked as outdated.

wesleywiser commented Feb 3, 2026

Uh oh!

rust-rfcbot commented Feb 3, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

petrochenkov commented Feb 3, 2026

Uh oh!

Noratrieb commented Feb 3, 2026

Uh oh!

hanna-kruppe commented Feb 3, 2026

Uh oh!

davidtwco commented Feb 17, 2026

Uh oh!

davidtwco commented Feb 17, 2026

Uh oh!

rust-rfcbot commented Mar 12, 2026

Uh oh!

petrochenkov commented Apr 17, 2026

Uh oh!

rust-rfcbot commented Apr 17, 2026

Uh oh!

wesleywiser commented Apr 28, 2026

Uh oh!

rust-bors Bot commented Apr 28, 2026

Uh oh!

wesleywiser commented Apr 28, 2026

Uh oh!

rust-bors Bot commented Apr 28, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

10 participants

davidtwco commented Feb 2, 2026 •

edited by rustbot

Loading

rust-rfcbot commented Feb 3, 2026 •

edited

Loading