Draft for the "0th" RFC

[nikomatsakis]

This draft includes the basic text for the 0th RFC. It has a few FIXMEs. The summary:

• First, to modify Rust functions with the "C" abi to abort on unwinding, as proposed
  in [Abort instead of unwinding past FFI functions rust#52652].
• Second, to introduce the "C unwind" ABI, with virtually all details
  (but not quite all) left as "to be determined".
  • The intent of this ABI, however, is to permit Rust panics to
    be "translated" into a "native" unwinding mechanism, though
    precisely which is dependent on the target platform or other
    compiler options.
    • (In practice, this translation is a no-op, since Rust panics
      use the native mechanism, but this is explicitly not
      required for the future.)
  • Folks currently using the "C" ABI to do unwinding can migrate to this new
    "C unwind" ABI, which captures their intentions. Their code is no more stable
    than it was, but they are on the right path.
• Finally, to create a "project group" with the purpose of designing subsequent
  RFCs to flesh out the details of the "C unwind" ABI
  • The "project group" term is newly introduced, but it corresponds
    to a kind of working group -- one with the goal of fleshing out
    a particular proposal or completing a project.
  • We aim to specify how "C unwind" works on major platforms
  • Goal is to enable Rust panics to propagate across native frames
  • And perhaps to enable native exceptions to propagate across Rust frames
  • But not to allow catching or throwing native exceptions from Rust code

[gnzlbg]

So this isn't really that related to longjmp, although longjmp exhibits this issue. As the text says, on these platforms, these longjmps are implemented using "native unwinds". The problem is that on these platforms "native unwinds" can behave differently, depending on, e.g., how they are thrown.

If this WG attacks the problem of how native unwinds behave in Rust, it would need to consider those potential differences in behavior.

I'm not sure how to word that into this section which appears more focused on the issue discovered while using rlua on windows.

[gnzlbg]

Suggested change

	such as C++.
	such as C++ or C with `-fexceptions`.

[gnzlbg]

Which compiler options do you have in mind here ?

I think that the "native" unwinding mechanism is part of the target ABI, i.e., part of the target triple. So there should be no way to change it via compiler options, doing so requires a completely different target.

For example, on windows, the mingw targets specify the unwinding ABI as part of their triple in the MinGW C toolchains ...-mingw-seh, ...-mingw-sjlj, etc.

Currently, for Rust, the x86_64-pc-windows-gnu and i686-pc-windows-gnu use the SEH abi. If we wanted to use the SJLJ abi there, a different target triple, e.g., x86_64-pc-windows-gnu-sjlj feels like a better idea, because not only the Rust part of the ABI implementation has to change, but we need to call the C compilers and linkers with different flags, link different platform libraries that use this other ABI, etc.

There is the potential use case of being able to link both C libraries that use SEH and C libraries that use SJLJ in such a platform, but then "C unwind" isn't enough, because it doesn't let you specify which ABI to use. Instead of maybe trying to make "C unwind" fit this use case, I think it would be better to leave solving this problem to some other language feature, e.g., adding two platform specific ABIs on that target only, like "C SEH" and "C SJLJ", or something like that. That kind of ABI information needs to propagate correctly through function pointers and such.

So I would change the text above to:

The intent of this ABI, however, is to permit Rust panics to
be "translated" into the "native" unwinding mechanism of the platform,
which is fixed by the platform target specification.

Note that this text is used below as well.

[gnzlbg]

One meta-comment is that the RFC suggest that "C unwind" is an ABI string that's available on all targets that Rust supports, just like "system" or "C", but the RFC does not explicitly state this anywhere, so the reader has to guess.

If we were to do that, the questions:

• What does "C unwind" do on targets that do not support any kind of unwinding (not even in Rust) at all? (AFAICT it would need to be identical to "C" ?)
• Will Rust specify / document what "C unwind" does for targets for which unwinding is implementable, and Rust does it in a certain way, but the platform doesn't use it nor specify it at all?

I don't think these questions are worth answering, and would prefer the RFC to not leave any room for those questions to appear. Specifying instead that "C unwind" is a platform-specific ABI string that's only available on some platforms that can properly support this feature, would mean that these situations would be compilation-errors, and we can re-visit them when a real use case for these appears.

[gnzlbg]

Suggested change

	* Second, to introduce the "C unwind" ABI, with virtually all details
	* Second, to introduce the target-specific "C unwind" ABI (available on some targets only), with virtually all details

[gnzlbg]

Suggested change

	* We aim to specify how "C unwind" works on major platforms
	* We aim to specify how "C unwind" works on major platforms, adding support for new targets incrementally

[gnzlbg]

Suggested change

	* Second, to introduce the "C unwind" ABI, with virtually all details
	* Second, to introduce the target-specific "C unwind" ABI (available on some platforms only), with virtually all details

[gnzlbg]

Suggested change

	* We aim to specify how "C unwind" works on major platforms
	* We aim to specify how "C unwind" works on major platforms, adding support for new targets incrementally

[gnzlbg]

Suggested change

	* But not to allow catching or throwing native exceptions from Rust code
	* But we don't know at this point if the working group will end up allowing catching or throwing native exceptions from Rust code

@acfoltzer I think something like this is what you meant ?

[gnzlbg]

So I'm not sure about these two paragraphs. I suppose that this a defense against "unknown unknowns" but I understand "C unwind" as "the C ABI + unwinding", so I kind of expect it to be equivalent to "C" when -C panic=abort, for example.

The C++ proposal is compatible with the C ABI, and there is also a C proposal for it that adds support for the same C++ feature to C without breaking the current call ABI (I'm not sure if it breaks the unwind ABI on some platforms though, but since the C standard doesn't have a concept of unwinding, it breaks nothing there at least).

[BatmanAoD]

Superseded by #28