Linking broken on arm64ec due to __rust_alloc_error_handler_should_panic symbol

[purplesyringa]

Attempting to link any program on the arm64ec target yields

error: linking with `link.exe` failed: exit code: 1120
  |
  = note: "C:\\Program Files\\Microsoft Visual Studio\\2022\\Enterprise\\VC\\Tools\\MSVC\\14.43.34808\\bin\\HostARM64\\arm64\\link.exe" "/NOLOGO" "C:\\Users\\RUNNER~1\\AppData\\Local\\Temp\\rustcou23Eq\\symbols.o" "<72 object files omitted>" "<sysroot>\\lib\\rustlib\\arm64ec-pc-windows-msvc\\lib/{libtest-*,libgetopts-*,libunicode_width-*,librustc_std_workspace_std-*,libstd-*,libpanic_unwind-*,libwindows_targets-*,librustc_demangle-*,libstd_detect-*,libhashbrown-*,librustc_std_workspace_alloc-*,libunwind-*,libcfg_if-*,librustc_std_workspace_core-*,liballoc-*,libcore-*,libcompiler_builtins-*}.rlib" "kernel32.lib" "kernel32.lib" "kernel32.lib" "kernel32.lib" "ntdll.lib" "userenv.lib" "ws2_32.lib" "dbghelp.lib" "/defaultlib:msvcrt" "/machine:arm64ec" "softintrin.lib" "/NXCOMPAT" "/LIBPATH:C:\\Users\\runneradmin\\.cargo\\registry\\src\\index.crates.io-1949cf8c6b5b557f\\windows_x86_64_msvc-0.52.6\\lib" "/OUT:C:\\a\\lithium\\lithium\\target\\arm64ec-pc-windows-
  = note: some arguments are omitted. use `--verbose` to show all linker arguments
  = note: symbols.o : error LNK2001: unresolved external symbol #_RNvCse3amHqTQ2bx_7___rustc39___rust_alloc_error_handler_should_panic (EC Symbol)␍
          symbols.o : error LNK2001: unresolved external symbol #_RNvCse3amHqTQ2bx_7___rustc39___rust_alloc_error_handler_should_panic (EC Symbol)␍
          C:\a\lithium\lithium\target\arm64ec-pc-windows-msvc\debug\deps\lithium-21aeb5d0fedc4d6a.exe : fatal error LNK1120: 1 unresolved externals␍

I think this was broken by #140809, more specifically 0cdd7f5 which started exporting all #[rustc_std_internal_symbol] symbols. __rust_alloc_error_handler_should_panic is a static, but is erroneously marked as a function and that breaks mangling. I've tried to draft a PR to mark it as Data, but I think might encounter the same problems as what eventually lead to #141061 and I'm not qualified to judge that.

cc @dpaoliello

Versions

My CI has passed on rustc 1.90.0-nightly (b03b3a7ec 2025-06-26) and now fails on rustc 1.90.0-nightly (35f603652 2025-06-29). I don't really have access to an ARM64 Windows machine other than that, but this is probably enough info? Here's the relevant Actions job.

@rustbot label +A-allocators +A-linkage +O-AArch64 +O-windows-msvc +T-compiler -needs-triage

[dpaoliello]

@bjorn3 should we also change __rust_alloc_error_handler_should_panic to be a function?

[purplesyringa]

FWIW, I'm happy that such a function would only be called on OOM, so performance implications of this change would be basically nil.

[bjorn3]

@bjorn3 should we also change __rust_alloc_error_handler_should_panic to be a function?

I guess. Still annoying that arm64ec windows doesn't properly support exporting statics.

[dpaoliello]

Oh, my bad, I didn't read through this carefully: this is a static but it's being exported as a function.

[bjorn3]

Right. For

rust/compiler/rustc_codegen_ssa/src/back/symbol_export.rs

Line 227 in c65dcca

mangle_internal_symbol(tcx, OomStrategy::SYMBOL),

we should use SymbolExportKind::Data at

rust/compiler/rustc_codegen_ssa/src/back/symbol_export.rs

Line 237 in c65dcca

kind: SymbolExportKind::Text,

[dpaoliello]

Verified locally that it fixes the issue. PR to fix: #143260

FYI @purplesyringa you don't need an Arm64 Windows machine to build for Arm64 or Arm64EC. If you have a Windows machine with the Arm64-targetting MSVC build tools installed, you can cross compile for Arm64 and Arm64EC.

[purplesyringa]

I'm just a bystander, but I'm a little confused: what difference between OomStrategy::SYMBOL and NO_ALLOC_SHIM_IS_UNSTABLE makes the straightforward SymbolExportKind::Data change work for the former but introduces linking problems described in #141061 for the latter?