Avoid using \u{1} prefixes in symbol names where possible

[bjorn3]

This prefix disables name mangling in LLVM, but other codegen backends don't support this. We also don't guarantee that it will remain working. As discussed in https://rust-lang.zulipchat.com/#narrow/stream/238009-t-compiler.2Fmeetings/topic/.5Bweekly.5D.202024-09-19/near/471499857 we may choose to add a #[link_name("foo", verbatim)] flag or similar to get the same effect and then deny all usage of \u{1} over an edition boundary.

[bjorn3]

See also rust-lang/rustc_codegen_cranelift#1520 for an example where this causes linking to fail with cg_clif as the \u{1} prefix gets passed straight to the linker.

[pvdrz]

hey Bjorn :)

I'm all-in if we could replace this hacky solution for something less brittle. Is there something we could do before the #[link_name("foo", verbatim)] is actually implemented?

[bjorn3]

Most of the time it should be possible to reverse the symbol mangling in rust-bindgen back to whatever would have been written in C before passing it to #[link_name] and thus avoid \u{1} most of the time. For the remaining cases where the symbol name doesn't match something that regular C mangling would produce, keeping usage of \u{1} until #[link_name("foo", verbatim)] is implemented is the best you can do I think.

[emilio]

Most of the time it should be possible to reverse the symbol mangling in rust-bindgen back to whatever would have been written in C

That's true for C, but not so easy for C++, right?

[bjorn3]

Outside of Windows it is possible to unmangle C++ names into something that cam be written in C (except for ABI tags as those need a dot, but that works fine with #[linkage_name] without \x01 already anyway). And for Windows C++ it is fine by me to keep using \x01 for now if necessary.