Some changes occurred in compiler/rustc_codegen_ssa

cc @WaffleLapkin

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.

For the Rust project, this means that anyone using the raw-dylib feature will need to provide the Arm64EC mangled name for any C++ function when targeting Arm64EC

How would that actually work? If you just do #[link_name = "..."] it would be provided to both LLVM (which mangles it) and ar_archive_writer (which doesn't mangle it) To disable the name mangling on the LLVM side you have to use \x01, but ar_archive_writer doesn't handle that and it is an LLVM implementation detail that may not work with other backends anyway.

For the Rust project, this means that anyone using the raw-dylib feature will need to provide the Arm64EC mangled name for any C++ function when targeting Arm64EC

How would that actually work? If you just do #[link_name = "..."] it would be provided to both LLVM (which mangles it) and ar_archive_writer (which doesn't mangle it) To disable the name mangling on the LLVM side you have to use \x01, but ar_archive_writer doesn't handle that and it is an LLVM implementation detail that may not work with other backends anyway.

Let's take the example from the LLVM bug I posted above: int Wrapper<X>::GetValue(void) const

For most arches this is mangled as ?GetValue@?$Wrapper@UA@@@@QEBAHXZ
But, for Arm64EC it is mangled as ?GetValue@?$Wrapper@UA@@@@$$hQEBAHXZ

So, with ar_archive_writer 0.4.2 writing #[link_name = "?GetValue@?$Wrapper@UA@@@@QEBAHXZ"] would generate an incorrect Arm64EC mangled name and so linking would fail. With 0.5.0, ar_archive_writer recognizes that it is not an Arm64EC mangled name and so raises an error.

There are cases where 0.4.2 got the Arm64EC mangling correct, and those will now raise an error.

If you do #[link_name = "?GetValue@?$Wrapper@UA@@@@$$hQEBAHXZ"] as already mangled name, then LLVM would mangle it again when it codegens a call to this function, right? Or actually it turns out LLVM literally crashes when you try that currently: https://rust.godbolt.org/z/Y6aj635qc

But if you use a simpler name where the old 0.4.2 algorithm happened to be correct, then it compiles correctly: https://rust.godbolt.org/z/dnhn64sqM but with 0.5.0 this will now raise an error.

So basically before this PR there were cases where the name mangling was wrong for C++ on arm64ec when using raw-dylib and in those cases there was no workaround. And with this PR you simply can't correctly use C++ symbols with raw-dylib at all.

Actually, the example that you provided works fine if you use raw-dylib: https://rust.godbolt.org/z/fofzhfs5G

I did some experiments with 0.4.2, and it did work correctly even with the incorrect Arm64EC mangling: turns out that we don't need the mangled name since the EXPORT_AS gets set to the unmangled name anyway. I'm going to make a slight change to ar_archive_writer that will allow us to avoid this error and continue to link against C++ mangled names.

Ok, workaround in ar_archive_writer: rust-lang/ar_archive_writer#26

☔ The latest upstream changes (presumably #145923) made this pull request unmergeable. Please resolve the merge conflicts.

This PR was rebased onto a different master commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

@bjorn3 I've updated with the workaround I added in ar_archive_writer, and verified via our internal build pipeline that the workaround works.

@bors r+

📌 Commit 4daae65 has been approved by bjorn3

It is now in the queue for this repository.

⌛ Testing commit 4daae65 with merge 7aef4be...

☀️ Test successful - checks-actions
Approved by: bjorn3
Pushing 7aef4be to master...

Comparing 154037f (parent) -> 7aef4be (this PR)

Test differences

cargo run --manifest-path src/ci/citool/Cargo.toml -- \
 test-dashboard 7aef4bec4bec16cb6204d51eb633873e23b18771 --output-dir test-dashboard

Job duration changes

1. dist-x86_64-apple: 5796.5s -> 7384.2s (27.4%)
2. aarch64-apple: 5868.5s -> 7320.6s (24.7%)
3. dist-arm-linux-gnueabi: 4930.1s -> 5505.5s (11.7%)
4. dist-i586-gnu-i586-i686-musl: 5882.8s -> 5344.6s (-9.1%)
5. x86_64-gnu-stable: 7490.7s -> 6980.0s (-6.8%)
6. x86_64-gnu-llvm-19-1: 3595.9s -> 3365.6s (-6.4%)
7. dist-aarch64-msvc: 6022.0s -> 5668.6s (-5.9%)
8. dist-various-2: 2173.7s -> 2055.1s (-5.5%)
9. x86_64-gnu-llvm-20-1: 3485.4s -> 3309.7s (-5.0%)
10. aarch64-gnu: 7284.9s -> 6925.5s (-4.9%)