Stabilize default_alloc_error_handler

[Amanieu]

Tracking issue: #66741

This turns feature(default_alloc_error_handler) on by default, which causes the compiler to automatically generate a default OOM handler which panics if #[alloc_error_handler] is not provided.

The FCP completed over 2 years ago but the stabilization was blocked due to an issue with unwinding. This was fixed by #88098 so stabilization can be unblocked.

Closes #66741

[rust-highfive]

r? @lcnr

(rust-highfive has picked a reviewer for you, use r? to override)

[lcnr]

considering that the FCP was 2 years ago, i would expect us to go through another FCP which explains the reason why stabilization was blocked. Won't block this without an FCP, but i definitely want someone to look at this who's a bit more knowledgeable about this than me

r? compiler

[bjorn3]

When using this with cg_clif I get:

           /home/gh-bjorn3/cg_clif/build_sysroot/sysroot_src/library/alloc/src/alloc.rs:419: undefined reference to `rust_oom'

It seems that the current implementation depends on -Zfunction-sections=yes, while cg_clif sets it to no for linker performance reasons. To elaborate on why it depends on this. The code in question is

pub mod __alloc_error_handler {
    use crate::alloc::Layout;

    // called via generated `__rust_alloc_error_handler`

    // if there is no `#[alloc_error_handler]`
    #[rustc_std_internal_symbol]
    pub unsafe fn __rdl_oom(size: usize, _align: usize) -> ! {
        panic!("memory allocation of {size} bytes failed")
    }

    // if there is an `#[alloc_error_handler]`
    #[rustc_std_internal_symbol]
    pub unsafe fn __rg_oom(size: usize, align: usize) -> ! {
        let layout = unsafe { Layout::from_size_align_unchecked(size, align) };
        extern "Rust" {
            #[lang = "oom"]
            fn oom_impl(layout: Layout) -> !;
        }
        unsafe { oom_impl(layout) }
    }
}

__rust_alloc_error_handler will be generated as a call to either of these functions. __rdl_oom when #![feature(default_alloc_error_handler)] is used, no problem here and __rg_oom when it isn't used. The problem is that in this case rust_oom (which is the actual symbol name of oom_impl) is not defined. In other words it only just so happens to work because __rg_oom is garbage collected by the linker by default. Both compiling liballoc with -Zfunction-sections=no and using -Clink-dead-code when compiling the executable or dylib will cause __rg_oom to not be garbage collected and thus give a linker error.

[Ericson2314]

I guess this is fine, but for people using alloc without global error handling at all (the current unstable cfg stuff, a feature hopefully someday) I hope one doesn't get needlessly synthesized.

[oli-obk]

We should probably have a test that uses this in a way we expect it to be used without requiring other feature gates. The tests touched by this PR all use other feature gates.

[rustbot]

rustc_error_messages was changed

cc @davidtwco, @compiler-errors, @JohnTitor, @estebank, @TaKO8Ki

[Amanieu]

@rustbot ready