RFC 2797: Cross-FFI unwinding WG

lang (panic | ffi)

Summary

Motivation

Unwinding through Rust's extern "C" ABI is Undefined Behavior. There is an existing plan to make the behavior of Rust's panic well-defined by causing Rust functions defined with extern "C" to abort the application whenever an uncaught panic would otherwise escape into the caller. Unfortunately, previous attempts to stabilize this behavior have caused existing, working projects to break.

The problem here is not that the existing projects break per se: they are relying on Undefined Behavior, so breakage is to be expected as a possibility. The problem is that there is no alternative available to them that would allow them to keep working (even if they are continuing to rely on behavior that is not yet fully specified).

Previous attempts to provide a well-defined mechanism for unwinding across FFI boundaries have failed to reach consensus. Notably, two proposed RFCs generated over 400 comments between them before ultimately being closed:

GitHub comment threads become difficult to follow for discussions this lengthy, and the disagreements in these threads have felt less productive than we believe they could be if more structure were provided.

We would also like to demonstrate the Rust lang team's commitment to providing such a mechanism without needing to agree in advance on what language changes will be stabilized in order to do so.

Prototyping 'shepherded' project groups

With this RFC, we formally announce the formation of a project-specific, shepherded "project group" to adopt responsibility for driving progress on specifying unwinding behavior at FFI boundaries.

What is a "project group"?

The "project group" term has not previously been used: it is intended to formalize a concept that has existed informally for some time, under a number of names (including "working group").

A "project group" is a group of people working on a particular project at the behest of an official Rust team. Project groups must have:

This blog post explains in detail the role of the shepherds.

Project group roadmap and RFCs

The first step of the project group is to define a roadmap indicating the planned sequence in which it will design and propose particular behaviors and features. Once the project group feels it has completed work on some item in the roadmap, that item will be submitted as an RFC or FCP for review by the lang team and the community at large.

Stabilizing unspecified "TBD" behavior

We would like to be able to provide features in stable Rust where some of the details are only partially specified. For example, we might add a new ABI "C unwind" that can be used from stable Rust, while explicitly leaving the behavior when a foreign exception unwinds across such a boundary unspecified. In such cases, we would attempt to provide some bounds on what might happen -- for example, we might state that a Rust panic propagating across a "C unwind" boundary must be preserved and handled as normal.

In some cases, we intend to mark some of this unspecified behavior as "To Be Determined" (TBD). This classification is meant to convey that the behavior is behavior we intend to specify as part of this group, although we have not done so yet. This categorization is purely intental to the working group, however; such behavior would remain formally unspecified until an RFC or other binding decision is reached.

Details of the FFI-unwind project group

Repository

Initial shepherds:

Lang team liaisons:

Charter

The FFI-unwind project group has the following initial scope:

Certain elements are considered out of scope, at least to start:

Constraints and considerations

In its work, the project-group should consider various constraints and considerations:

Participation in the project group

Like any Rust group, the FFI-unwind project group intends to operate in a public and open fashion and welcomes participation. Visit the repository for more details.

Drawbacks

Prior art

Although the term "project group" is new, some existing efforts, such as the Unsafe Code Guidelines effort and the work around defining const evaluation, were organized in a similar fashion.

In addition to the blog post Niko Matsakis about shepherding, James Munns wrote a more formal shepherding proposal.

The governance WG and lang-team meta working group were both formed at least in part to improve the process for large-scale design efforts. One existing proposal is for "staged RFCs"; this may be considered a precursor to the current "shepherded project group" proposal.

Unresolved questions and Future possibilities

Since this RFC merely formalizes the creation of the project group, it intentionally leaves all technical details within the project's scope unresolved.

Future possibilities

The project group will start with a fairly limited scope, but if the initial effort to design and stabilize a safe cross-language unwinding feature on a limited set of platforms goes well, there are many related areas of potential exploration. Three noteworthy examples are: