Make __rust_alloc_error_handler_should_panic a function

[dpaoliello]

Fixes #143253

__rust_alloc_error_handler_should_panic is a static but was being exported as a function.

For most targets this doesn't matter, but Arm64EC Windows uses different decorations for exported variables vs functions, hence it fails to link when -Z oom=abort is enabled.

We've had issues in the past with statics like this (see #141061) but the tldr; is that Arm64EC needs symbols correctly exported as either a function or data, and data MUST and MUST ONLY be marked dllimport when the symbol is being imported from another binary, which is non-trivial to calculate for these compiler-generated statics.

So, instead, the easiest thing to do is to make __rust_alloc_error_handler_should_panic a function instead.

Since __rust_alloc_error_handler_should_panic isn't involved in any linking shenanigans, I've marked it as AlwaysInline with the hopes that the various backends will see that it is just returning a constant and perform the same optimizations as the previous implementation.

r? @bjorn3

[rustbot]

Some changes occurred in compiler/rustc_codegen_cranelift

cc @bjorn3

Some changes occurred in compiler/rustc_codegen_gcc

cc @antoyo, @GuillaumeGomez

[bjorn3]

Since __rust_alloc_error_handler_should_panic isn't involved in any linking shenanigans, I've marked it as AlwaysInline with the hopes that the various backends will see that it is just returning a constant and perform the same optimizations as the previous implementation.

That won't have any effect. It is part of the allocator shim object file, which doesn't participate in LTO unless you use -Clinker-plugin-lto. With -Clinker-plugin-lto it should in principle always be inlined even without that attribute. Still can't hurt to have it I guess.

[rustbot]

The Miri subtree was changed

cc @rust-lang/miri

[bjorn3]

r=me with CI passing

[bjorn3]

@bors r+

[bors]

📌 Commit 2b22d0f has been approved by bjorn3

It is now in the queue for this repository.

[tgross35]

Since this is changing to a new _v2 name now, why not make it a static rather than a function call?

[RalfJung]

IIUC that's very hard to do correctly on arm64ec, and because one fairly niche platform makes this (needlessly?) complicated, we have to use a less optimal solution on all platforms...

(I guess we could switch between function and data variable depending on the target, but that'd mean even more hacks in rustc.)

[tgross35]

Ah, that's the dllimport comment in the top post? Makes sense. If the situation improves, v3 can be a static 😆