Hey @WG-ffi-unwind -- should we sync? Do we want to try this over zoom to move faster maybe?
Yes, I was planning to do it with Zoom.
aaa sorry, I didn't realize we had settled on a time. I'll be able to join in ~10 minutes
( cc @Amanieu :point_up: )
not sure why you're not in the alias :)
something we said at the made me realize the catch with 1C
which is basically that one of our goals was to add shims in Cpanic=unwind to catch exceptions across the "C" boundary
since it is Cpanic=unwind, we cannot just make dtors abort
so we have to have a shim that permits longjmp but not other exceptions, presumably
which means that you can't say "UB to unwind if there are destrutors in scope" without clarifying the kind of unwinding
even so .. I think it might be preferable, or else a variant 1d where you say
but honestly I'm not convinced that the cure here is worse than the disease...
I should raise one other option
ok, I wrote out the other option. In short, if we sacrifice C++ exception interop, you get what seems to me to be a relatively minimal diff on today's ABI, and one that leaves some room for future decisions:
You need the forced exception distinction if you want to insert shims in
-Cpanic=abort mode, you can add shims to destructor calls to abort, since they should neve run.
In both cases, you probably only want the shims in debug builds, but they correspond to cases that are supposed to be UB.
what would these shims be for? aborting on a non-Rust, non-forced exception?
Yes, just catching accidental propagation
Maybe there's not much point