Stream: project-ffi-unwind

Topic: #[ffi_no_unwind]


gnzlbg (Oct 24 2019 at 07:32, on Zulip):

I think a #[ffi_no_unwind] attribute for FFI declarations only would be ok

gnzlbg (Oct 24 2019 at 07:32, on Zulip):

For extern "C" fn foo() { ... } definitions in Rust, the attribute should not be necessary

gnzlbg (Oct 24 2019 at 07:32, on Zulip):

Since the compiler should be able to properly deduce whether that function can or cannot be nounwind

gnzlbg (Oct 24 2019 at 07:37, on Zulip):

Semantically, those who want to make those extern "C" Rust definitions abort can already do so by just using catch_unwind, so while we could add a "proc macro" that does it for them, it shouldn't be necessary for an MVP

gnzlbg (Oct 24 2019 at 07:38, on Zulip):

The MVP could just be "unwinding from extern "C" is ok, and for extern "C" declarations only there is a #[ffi_no_unwind] attribute that you can use."

gnzlbg (Oct 24 2019 at 07:39, on Zulip):

The "unwinding from extern "C" is ok" guarantee could be worded carefully, to say that it unwinds with a platform unwind, meaning that we on paper "translate" a Rust unwind to a platform unwind, so that this does not stabilize nor constrain the Rust unwind implementation details.

Last update: Jan 28 2020 at 01:35UTC