`c_unwind` full stabilization request: change in `extern "C"` behavior

[BatmanAoD]

Tracking issue: #74990

This is a separate issue to enable using the FCP bot a second time. The request-for-stabilization comment is duplicated below, without modification.

RFC "C-unwind ABI": rust-lang/rfcs#2945

Feature gate to be stabilized: #![feature(c_unwind)]

Stabilization PR: #116088

[BatmanAoD]

Request for Stabilization

This is a request for full stabilization of the c_unwind feature, RFC-2945. The behavior of non-"Rust", non-unwind ABIs (such as extern "C") will be modified to close soundness holes caused by permitting stack-unwinding to cross FFI boundaries that do not support unwinding.

Summary

When using panic=unwind, if a Rust function marked extern "C" panics (and that panic is not caught), the runtime will now abort.

Previously, the runtime would simply attempt to unwind the caller's stack, but the behavior when doing so was undefined, because extern "C" functions are optimized with the assumption that they cannot unwind (i.e. in rustc, they are given the LLVM nounwind annotation).

This affects existing programs. If a program relies on a Rust panic "escaping" from extern "C":

• It is currently unsound.
• Once this feature is stabilized, the program will crash when this occurs, whereas previously it may have appeared to work as expected.
• Replacing extern "x" with extern "x-unwind" will produce the intended behavior without the unsoundness.

The behavior of function calls using extern "C" is unchanged; thus, it is still undefined behavior to call a C++ function that throws an exception using the extern "C" ABI, even when compiling with panic=unwind.

Changes since the RFC

None.

Unresolved questions

This feature does not affect the behavior of pthread_exit or longjmp, so stabilization will neither break existing code using these features nor provide any soundness guarantee.

Tests

"C" guaranteed to abort on panic

This test verifies that an extern "C" function that panic!s will always abort if the panic would otherwise "escape".

Documentation

The documentation PRs for this feature did not distinguish between the initial partially-stabilized behavior and the fully-stabilized behavior, so they already include the modifications to non-unwind ABIs.

• The Rustonomicon PR has already been merged.
• The Reference PR is still awaiting approval.

I've also opened an issue to discuss adding a brief note about this feature in the Book.

[joshtriplett]

@rfcbot merge

[rfcbot]

Team member @joshtriplett has proposed to merge this. The next step is review by the rest of the tagged team members:

• @joshtriplett
• @nikomatsakis
• @pnkfelix
• @scottmcm
• @tmandry

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
See this document for info about what commands tagged team members can give me.

[nbdd0121]

cc @rust-lang/wg-ffi-unwind

[tmandry]

• Once this feature is stabilized, the program will crash when this occurs, whereas previously it may have appeared to work as expected.

Do we have a crater run showing the impact of this? I'd prefer to give the ecosystem time to update their code ahead of crashing everyone's programs (even if they're technically already broken).

That said, we will need some way of alerting all the broken libraries.

[nbdd0121]

We could do the crater run on the PR (still under preparation, sorry!)

[BatmanAoD]

I do think it makes sense to do a crater run before actually approving the stabilization.

[traviscross]

@rustbot labels +I-lang-nominated

Nominating so we can discuss what needs to happen to move this forward.