Avoid \u{1} prefix when the user overrode item names#3175
Avoid \u{1} prefix when the user overrode item names#3175bjorn3 wants to merge 1 commit intorust-lang:mainfrom
Conversation
bjorn3
changed the title
bjorn3
force-pushed
the
better_link_name_handling
branch
from
fc322e0 to
50eb27f
Compare
|
Why does the Publish on crates.io workflow get invoked even though this PR hasn't been merged? It gives me a failure notification. https://github.com/rust-lang/rust-bindgen/actions/runs/13972867609 |
|
Right, for Mach-O all symbols get mangled to add an |
cc @pvdrz . My understanding is that it's not supposed to run, but maybe these fields are an rust-bindgen/.github/workflows/publish.yml Lines 3 to 8 in a50a2cf |
|
What is missing from this PR to be accepted? |
\u{1} is an LLVM specific extension which other rustc codegen backends
do not support.
bjorn3
force-pushed
the
better_link_name_handling
branch
from
50eb27f to
da9e06b
Compare
| ][::std::mem::offset_of!(JNINativeInterface_, __hack) - 8usize]; | ||
| }; | ||
| unsafe extern "stdcall" { | ||
| #[link_name = "\u{1}_bar@0"] |
There was a problem hiding this comment.
This PR causes new \u{1} for extern "stdcall".
There was a problem hiding this comment.
This wouldn't break things further for cg_clif. extern "stdcall" already isn't supported anyway due to cg_clif not implementing the symbol mangling for it anyway.
|
I don't think the CI failure is related to this PR. It seems to be a dylib issue with git. |
|
This may be enough of a temporary fix for now. Implementing demangling inside rust-bindgen would be a better long term solution, but also more work. |
|
@emilio do you need more to accept and release this PR? |
3 participants
\u{1}is an LLVM specific extension which other rustc codegen backends do not support.Fixes #2935