diff options
| author | bors <bors@rust-lang.org> | 2025-03-17 22:16:22 +0000 |
|---|---|---|
| committer | bors <bors@rust-lang.org> | 2025-03-17 22:16:22 +0000 |
| commit | 493c38ba371929579fe136df26eccd9516347c7a (patch) | |
| tree | 484a8d1c5a27edeb82df4d542a715b45975c5d4b /.github | |
| parent | 43a2e9d2c72db101f5fedac8b3acb78981b06bf2 (diff) | |
| parent | bebc5026b109bf5522185ae8bd1c3f0cbabe6acd (diff) | |
| download | rust-493c38ba371929579fe136df26eccd9516347c7a.tar.gz rust-493c38ba371929579fe136df26eccd9516347c7a.zip | |
Auto merge of #127173 - bjorn3:mangle_rustc_std_internal_symbol, r=wesleywiser,jieyouxu
Mangle rustc_std_internal_symbols functions This reduces the risk of issues when using a staticlib or rust dylib compiled with a different rustc version in a rust program. Currently this will either (in the case of staticlib) cause a linker error due to duplicate symbol definitions, or (in the case of rust dylibs) cause rustc_std_internal_symbols functions to be silently overridden. As rust gets more commonly used inside the implementation of libraries consumed with a C interface (like Spidermonkey, Ruby YJIT (curently has to do partial linking of all rust code to hide all symbols not part of the C api), the Rusticl OpenCL implementation in mesa) this is becoming much more of an issue. With this PR the only symbols remaining with an unmangled name are rust_eh_personality (LLVM doesn't allow renaming it) and `__rust_no_alloc_shim_is_unstable`. Helps mitigate https://github.com/rust-lang/rust/issues/104707 try-job: aarch64-gnu-debug try-job: aarch64-apple try-job: x86_64-apple-1 try-job: x86_64-mingw-1 try-job: i686-mingw-1 try-job: x86_64-msvc-1 try-job: i686-msvc-1 try-job: test-various try-job: armhf-gnu
Diffstat (limited to '.github')
0 files changed, 0 insertions, 0 deletions
