Change Allocation error default behaviour

[XAMPPRocky]

Proposal

There have been a couple discussions about using Rust in larger systems. One of the current gotchas around using Rust in this context is that allocation errors (such as Out Of Memory) cause an abort by default.

Since aborts are not recoverable, this means that any call into the Rust component can unintentionally bring down the whole system. Thankfully this can be overridden with std::alloc::set_alloc_error_hook. There are two major issues with the current solution however.

The first is that this is currently a nightly API with no clear path to stabilisation, so this requires you to use nightly compiler for your library, even if you the rest of your crate only uses stable features. The second is that this is not supposed to work. The alloc error function is currently set as #[rustc_allocator_nounwind] but panic unwinding inside it works anyway.

Instead of stabilising this API I would like to propose changing the default alloc error implementation to panic, this would allow allocation errors to be caught at the FFI boundary on stable, without having to stabilise the override hook API. This would also remove the need for FFI libraries to expose a unset_abort or similar function to override the default behaviour. For panic=abort users there will be essentially no changes.

Related Issues

• Tracking issue for the OOM hook (alloc_error_hook) rust#51245

Mentors or Reviewers

Process

The main points of the Major Change Process is as follows:

• File an issue describing the proposal.
• A compiler team member or contributor who is knowledgeable in the area can second by writing @rustbot second.
  • Finding a "second" suffices for internal changes. If however you are proposing a new public-facing feature, such as a -C flag, then full team check-off is required.
  • Compiler team members can initiate a check-off via @rfcbot fcp merge on either the MCP or the PR.
• Once an MCP is seconded, the Final Comment Period begins. If no objections are raised after 10 days, the MCP is considered approved.

You can read more about Major Change Proposals on forge.

Comments

This issue is not meant to be used for technical discussion. There is a Zulip stream for that. Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.

[rustbot]

This issue is not meant to be used for technical discussion. There is a Zulip stream for that. Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.