Tracking Issue for "C-unwind ABI", RFC 2945

[nikomatsakis]

This is a tracking issue for the RFC "C-unwind ABI" (rust-lang/rfcs#2945).

The feature gate for the issue is #![feature(c_unwind)].

This RFC was created as part of the ffi-unwind project group tracked at rust-lang/lang-team#19.

About tracking issues

Tracking issues are used to record the overall progress of implementation.
They are also uses as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.

Steps

• Implement the RFC
• Adjust behavior of panic extern "C" fn"
  • panic in a no-unwind function leads to not dropping local variables #123231
  • Make destructors on extern "C" frames to be executed #129582
• Adjust documentation
  • panic runtime and C-unwind documentation reference#1226
• Stabilization PR (see instructions on rustc-dev-guide)

Implementation notes

Major provisions in the RFC:

• Add a C-unwind ABI and system-unwind (I think), we may need more variants.
• For external functions with the C ABI, we already (I believe) add the "nounwind" LLVM attributes when we build them. We want to continue doing this.
• For external functions with the C-unwind ABI, we do not want any such attributes.
• For Rust functions defined with the C ABI, e.g., extern "C" fn foo() { ... }, we want to force them to abort if there is a panic. The MIR helper function should_abort_on_panic already exists and I think will modify the generated code to insert the required shims in such a case. They should also be marked as "nounwind" in LLVM, if they're not already.
• Rust functions with the "C-unwind" ABI should not abort on panic.
• Use ABI to guide the "nounwind" attribute on callsites as well.
• Write suitable codegen tests to check generated LLVM IR.

Unresolved Questions

None. The unresolved questions in the RFC were meant to be solved by future RFCs building on this one.

Implementation history

• Initial implementation: Implement RFC 2945: "C-unwind" ABI  #76570
• Additional work (removing #[unwind], adjusting panic handling): rustc: Fill out remaining parts of C-unwind ABI #86155

[cratelyn]

Hello! I would be interested in helping implement this RFC. 🙋

(cc: @aturon)

[nikomatsakis]

Hey @katie-martin-fastly, that's great news! I'm going to assign you to the issue for now:

@rustbot assign @katie-martin-fastly

One thing to mention is that most Rust compiler development discussion takes place on the rust-lang zulip, and this project in particular is chatting in #project-ffi-unwind. I or @Amanieu are probably reasonable people to ping with questions. Also, for general "getting started" tips on building and testing the Rust compiler, the rustc-dev-guide is your friend. Also, rust-analyzer works well for IDE support (e.g., with vscode), though it requires a small bit of configuration since rustc doesn't build with cargo but rather the x.py script. (I couldn't find any documentation on that, I'll ping a few others and see...)

That said, in terms of mentoring and getting started, I think the idea is going to be to adapt an existing mechanism that the compiler offers. We have this attribute #[unwind(allowed)] which allows users to mark functions as permitting unwinding -- that mechanism is basically going to be deprecated and replaced with this new ABI, though I think it'd be best to add the ABI before trying to adapt the unwind attribute code. Still, searching for code related to that attribute will give you a good idea of what needs to change.

I can do more mentoring instructions later but, as a starting point, I updated the head post with some of the major goals of the RFC (see the "Implementation notes") section. Also here are some tips to get you started in terms of reading into the rustc code:

• The Abi enum lists out all the known ABIs (there may be more similar enums, not sure). We'll want to extend it with C-unwind and perhaps other unwind variants. One way to do this might be to change the C variant to C { unwind: bool } or something like that, or maybe just add a Cunwind, not sure.
• The UnwindAttr type records what kind of unwind attribute is placed on a particular function (is unwinding allowed? does it force an abort?)
• The find_unwind_attr function checks for what unwind attribute is placed on a particular function.
• The should_abort_on_panic function is used to decide when a function ought to, well, abort if a panic occurs (as the name suggests).
• The [can_unwind] field of this struct seems to be used to set the LLVM attribute "nounwind". I'm not quite sure where it gets set, but I have to stop now because it's Saturday :P so I'll leave that as an exercise to the reader.