Basically, C++ can catch a Rust panic with
catch (...) and then decide not to rethrow it. #67711 makes sure that the
Box<Any> is properly freed in this case, so we don't leak memory.
However this does affect the way Rust handles double-panics. The problem is that
panic_count in TLS is incremented when the panic is thrown, but not decremented when the panic is caught and destroyed by C++.
This means that the next time a panic occurs, Rust will think that it is a double-panic and abort immediately.
Now the question is, do we want to allow FFI code to catch and discard Rust panics?
If yes, then we need to rework
panic_count and the way double-panics work.
If not then we can abort in the exception destructor if it is called outside of
catch_unwind, just like
The main user-visible impact is that backtraces when a double-panic occurs will be slightly less precise: the second panic is treated as a normal panic (backtrace depends on RUST_BACKTRACE), but we will abort a bit later in the landing pad for the destructor which calls
abort instead of
I think we probably don't want to allow that, at least not now, but it's a good issue to raise
Aborting in the exception destructor sounds like the right approach to me. That way C++ can still catch the exception as long as it re-throws it, correct?
Yes, C++ can catch and rethrow it. Just not catch and ignore it.
Yep, that sounds good to me.