switch to v0 mangling by default on stable

[davidtwco]

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

[rustbot]

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

[rustbot]

⚠️ 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]

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

[Kobzol]

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]

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

[wesleywiser]

@rfcbot fcp merge compiler

[rust-rfcbot]

Team member @wesleywiser has proposed to merge this. The next step is review by the rest of the tagged team members:

• @Mark-Simulacrum
• @SparrowLii
• @cjgillot
• @davidtwco
• @estebank
• @jieyouxu
• @matthewjasper
• @nagisa
• @oli-obk
• @petrochenkov
• @spastorino
• @wesleywiser

Concerns:

• late-anon-const (switch to v0 mangling by default on stable #151994 (comment))

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[petrochenkov]

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]

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]

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

[davidtwco]

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]

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]

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

[rust-rfcbot]

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

[petrochenkov]

@rfcbot concern late-anon-const

#143361 added a new letter to the v0 mangling scheme - k for DefPathData::LateAnonConst, as opposed to long existing K for DefPathData::AnonConst.
We'd like to revert #143361 (in some sense) and migrate to passing per-owner disambiguators, because the approach from that PR is not very scalable and leaks internal details (requires extending mangling scheme every time we need some new desugaring during AST -> HIR lowering).
So k will be removed as well.

Questions: Can stable features produce "late anon consts"? Can we remove k if this PR lands and v0 becomes stable?

[BoxyUwU]

From what I can tell of #143361 there are three cases we get DefPathData::LateAnonConst

First (and most common) would be:

const FOO: usize = 10;
struct Bar<const N: usize>;
type Foo = Bar<FOO>;

Here the FOO argument to Bar is ambiguous at parse time and represented as a type argument, then during AST lowering we look at nameres results and see its actually a path to sth in the value namespace and create a late anon const

This matters for stable 🤔

The second case is rustc_legacy_const_generics:

#[rustc_legacy_const_generics(0)]
fn foo<const N: usize>() {}

fn main() {
    foo(1 + 1)
}

in this example during AST lowering we look at the resolution of foo to check for legacy const generics and rewrite the 1 + 1 to a late anon const (i.e. foo::<anon>())

This also matters for stable as rustc_legacy_const_generics is exposed by stdarch

The third case is pattern types stuff 🤔 Which is an unstable feature but I think oli wants to use them on stable as an impl detail which would expose that too (cc @oli-obk). Though I don't remember why these need to be a late anon const and would be interested in whether that can "just" be done in the DefCollector 🤔

---

Regardless of the above, I wanted to clarify something here:

Can we remove k if this PR lands and v0 becomes stable?

v0 is currently stable (just not the default) and can be (and is currently) used by users on stable. So (unfortunately) I think we're actually already exposing the different mangling of late anon consts to stable users ^^' Certainly making v0 the default would make it significantly more common this to be encountered tho.

I think we're already at the point where extending the mangling scheme in ways that are stable observable should not be done without some kind of sign off (which #143361 did not get)