Support for generating bindings with the C-unwind ABI

[lopopolo]

Feature request for generating bindings with the C-unwind ABI for generated functions and function pointers. I'd love for this to be supported both via the bindgen Rust API and CLI.

See:

• RFC: 'C-unwind' ABI rfcs#2945 (comment)
• RFC: 'C-unwind' ABI rfcs#2945 (comment)
• Add default trait implementations for "c-unwind" ABI function pointers rust#101263

[CAD97]

extern "system" is also useful.

[lopopolo]

rust-lang/rust#101263 was just merged so as of the next nightly, structs with C-unwind fn pointers will be able to implement Debug. I believe this is unblocked.

[pvdrz]

@lopopolo @CAD97. When would a function be tagged as extern "C-unwind" instead of extern "C" systematically?

[CAD97]

A function MUST be marked extern "C-unwind" if it uses the C ABI (e.g. because it is linked by name e.g. between Rust and C/C++) and an unwind can ever cross it (e.g. a Rust panic or C++ exception). A function SHOULD be marked extern "C" if it is known that it will never be unwound over. A function MUST be extern "C" to be callable from standard C. (Most platforms offer a way to compile "unwind compatible" C, however, as well as of course extern "system".)

As far as I'm aware, on all current platforms which support extern "C-unwind", the only difference in ABI between "C" and "C-unwind" is out-of-band (i.e. using "C-unwind" where "C" is expected will cause no issues). However, an ABI where this is not the case is simple to imagine (e.g. a reserved exception pointer register rather than out-of-band unwinding).

[pvdrz]

ok my question is a bit less broad than that. How can bindgen determine from the headers if a function is C or C-unwind?

[lopopolo]

My understanding is the decision to mark a function as C ABI or C-unwind ABI depends on whether the code is compiled with -fexceptions or C++ exceptions enabled.

This is an out of band configuration that is passed to the C/C++ compiler, so I'd expect a configuration option for bindgen to alter its behavior.