Bump rustc-demangle to 0.1.28

[teor2345]

This PR is part of the splat lang experiment: #153629

It brings in the changes from rust-lang/rustc-demangle#90, which encode splatted types with a w prefix in type mangling. This is required to fix the symbol clashes in #158644.

We need to upgrade the compiler and standard library to avoid "can't demangle" panics or errors. Some tools might work without the upgrade, but we might as well do it there as well.

@rustbot label +C-enhancement +F-splat +T-compiler +A-name-mangling

[rustbot]

stdarch is developed in its own repository. If possible, consider making this change to rust-lang/stdarch instead.

cc @Amanieu, @folkertdev, @sayantn

These commits modify the Cargo.lock file. Unintentional changes to Cargo.lock can be introduced when switching branches and rebasing PRs.

If this was unintentional then you should revert the changes before this PR is merged.
Otherwise, you can ignore this comment.

clippy is developed in its own repository. If possible, consider making this change to rust-lang/rust-clippy instead.

cc @rust-lang/clippy

These commits modify the library/Cargo.lock file. Unintentional changes to library/Cargo.lock can be introduced when switching branches and rebasing PRs.

If this was unintentional then you should revert the changes before this PR is merged.
Otherwise, you can ignore this comment.

[rustbot]

r? @jhpratt

rustbot has assigned @jhpratt.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

• Owners of files modified in this PR: libs
• libs expanded to 12 candidates
• Random selection from Darksonn, JohnTitor, Mark-Simulacrum, clarfonthey, jhpratt

[teor2345]

r? @wesleywiser

[Mark-Simulacrum]

@bors r+

However, I'm confused why splat needs custom mangling -- note that implies it will not demangle properly until downstream toolchains (perf, kernel, profilers, etc.) all update which will take years. Isn't #[splat] desugaring into an already supported form on stable today? Maybe we can mangle as-if there was (a, b, c) argument instead? Note that historically we have sometimes managed to find pre-existing options in the mangling (e.g., f16 and f128 iirc didn't need adjustments to rustc-demangle although I may be misremembering).

Obviously not too important while it's all unstable but worth thinking about during stabilization.

[rust-bors]

📌 Commit 82f4112 has been approved by Mark-Simulacrum

It is now in the queue for this repository.

[teor2345]

However, I'm confused why splat needs custom mangling -- note that implies it will not demangle properly until downstream toolchains (perf, kernel, profilers, etc.) all update which will take years. Isn't #[splat] desugaring into an already supported form on stable today? Maybe we can mangle as-if there was (a, b, c) argument instead? Note that historically we have sometimes managed to find pre-existing options in the mangling (e.g., f16 and f128 iirc didn't need adjustments to rustc-demangle although I may be misremembering).

Yeah that's a good question. Splat is treated as a distinct function type, because it is de-tupled in the callee, but tupled in the caller (at typecheck time). It's currently lowered to the tupled type, but in future we want to lower it de-tupled for performance. So I guess we could mangle the types the same way as the de-tupled form, once we make that change. This would need changes to the legacy and v0 mangling schemes to de-tuple when they see splat.

While it's incomplete, it's useful to have the symbols be distinct, so we don't lock ourselves into either option. And it avoids symbol clashes, see #158644 for details.

Obviously not too important while it's all unstable but worth thinking about during stabilization.

I've added a note to the tracking issue to review this before stabilisation