Handle panicking in "extern" fns more safely

[Lej77]

I was looking through the source code of this crate after reading the article Plugins in Rust: Reducing the Pain with Dependencies | NullDeref and I noticed that currently panicking is only handled for the LocalBorrowingFfiFuture::poll method and even that could be better since the Box that the is caught could panic when it is dropped, see Footgun with catch_unwind when catching panic-on-drop types · Issue #86027 · rust-lang/rust. This crate should probably do something similar to the preposed drop_unwind fn or to the AbortBomb in abi_stable.

All of the following extern "C" functions should probably handle panics since they call arbitrary user provided functions:

• LocalBorrowingFfiFuture::drop
• LocalBorrowingFfiFuture::poll (currently handled except for caught panic payloads that panic when dropped)
• FfiWaker(reference)::wake_by_ref
• FfiWaker(reference)::clone
• FfiWaker(owned)::drop
• FfiWaker(owned)::wake_by_ref
• FfiWaker(owned)::wake
• FfiWaker(owned)::clone

[Lej77]

The new code looks good and I can't find any safety issues with it.

I do think that the abort message should be Waker::clone and not Waker::drop at line 194 for the owned vtable clone method.

Also in the poll_fn function, is there a reason to not call Pin::new_unchecked and (*context_ptr).with_context inside the catch_unwind closure (seems like that would be safer if that code was ever changed to introduce a panic somewhere even if they can't panic currently).

[oxalica]

I do think that the abort message should be Waker::clone and not Waker::drop at line 194 for the owned vtable clone method.

Also in the poll_fn function, is there a reason to not call Pin::new_unchecked and (*context_ptr).with_context inside the catch_unwind closure (seems like that would be safer if that code was ever changed to introduce a panic somewhere even if they can't panic currently).

Thanks for the review. They are both fixed in b81ef7f now. Documentations are also updated on master.