Update to ar_archive_writer 0.5.0

[dpaoliello]

This updates ar_archive_writer to 0.5.0, which in turn was updated to match LLVM 20.1.8: rust-lang/ar_archive_writer#24

As part of this, I refactored part of SymbolWrapper.cpp to pull common code that I was about to duplicate again into a new function.

NOTE: ar_archive_writer does include a breaking change where it no longer supports mangling C++ mangled names for Arm64EC. 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 (0.4.2 supported doing this, but the algorithm was wrong).

r? @bjorn3

[rustbot]

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.

[bjorn3]

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.

[dpaoliello]

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.

[bjorn3]

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

[dpaoliello]

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.

[bjorn3]

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.

[dpaoliello]

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.

[dpaoliello]

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