diff --git a/compiler/rustc_codegen_ssa/src/back/symbol_export.rs b/compiler/rustc_codegen_ssa/src/back/symbol_export.rs index 60ab29193525..20881093f97b 100644 --- a/compiler/rustc_codegen_ssa/src/back/symbol_export.rs +++ b/compiler/rustc_codegen_ssa/src/back/symbol_export.rs @@ -577,6 +577,9 @@ pub(crate) fn linking_symbol_name_for_instance_in_crate<'tcx>( } let prefix = match &target.arch[..] { + "x86" | "x86_64" if target.is_like_msvc && undecorated.starts_with("?") => { + return undecorated; + } "x86" => Some('_'), "x86_64" => None, "arm64ec" => Some('#'), diff --git a/tests/ui/symbol-names/symbol-with-question-mark-links.rs b/tests/ui/symbol-names/symbol-with-question-mark-links.rs new file mode 100644 index 000000000000..5d46f0556555 --- /dev/null +++ b/tests/ui/symbol-names/symbol-with-question-mark-links.rs @@ -0,0 +1,25 @@ +// This test ensures functions with an exported name beginning with a question mark +// successfully compile and link. +// +// Regression test for + +//@ build-pass +//@ only-windows +//@ only-x86 +// Reason: This test regards a linker issue which only applies to Windows. +// Specifically, it only occurs due to Windows x86 name decoration, combined with +// a mismatch between LLVM's decoration logic and Rust's (for `lib.def` generation) + +#![crate_type = "cdylib"] + +#[no_mangle] +pub extern "C" fn decorated(a: i32, b: i32) -> i32 { + 1 +} + +// This isn't just `?undecorated` because MSVC's linker fails if the decorated +// symbol is not valid. +#[export_name = "?undecorated@@YAXXZ"] +pub extern "C" fn undecorated(a: i32, b: i32) -> i32 { + 2 +}