Report allocation errors through the panic handler · Issue #192 · rust-lang/libs-team (original) (raw)

Proposal

Problem statement

We currently use a completely separate mechanism to handle allocation errors (OOM) than panics, despite both of these being very similar. However both are very similar: they involve handling runtime failures that are generally unrecoverable. It would be better to unify them under a single mechanism which is already stable: panic handlers (no_std) and panic hooks (std).

Motivation, use-cases

This change has already been done for no_std in rust-lang/rust#66741: it was noticed that the vast majority of users of #[alloc_error_handler] were just calling panic anyways. This avoided the need to stabilize the alloc_error_handler attribute by defaulting to a panic if one was not specified.

The OOM hook API has also remained unstable for a very long time with no clear path to stabilization. The best way forward would be to unify it with the panic hook API just like it has been done in no_std.

Some use cases (firefox) still need access to the size of the failed allocation, so this is provided as a custom panic payload.

Solution sketches

// alloc::alloc

pub struct AllocErrorPanicPayload { .. }

impl AllocErrorPanicPayload {
    pub fn layout(&self) -> Layout;
}

This ACP proposes to make the following changes:

In the standard library, no additional allocations are made as part of the OOM handling process, except in 1 specific situation:

Tracking issues that will be closed by this change:

What happens now?

This issue is part of the libs-api team API change proposal process. Once this issue is filed the libs-api team will review open proposals in its weekly meeting. You should receive feedback within a week or two.