Hey @gnzlbg I want to follow up on some of the comments from the dropbox paper that I kind of dropped on the floor. In particular, you wrote this and I want to clarify what you mean:
But just adding extern "C panic" constraints the Rust unwinding ABI, e.g., to be compatible with the C calling convention. It’s hard for me to tell whether adding this constraint is worth it without knowing which problems the feature actually solves.
Are you referring here to "C panic" in the sense of "C with the Rust unwinding mechanism"? In other words, do you feel differently if we adopt "C unwind", where it is defined as "the 'native' unwind mechanism for the target"? This would presumably mean that if Rust and the target's unwinding mechanisms should diverge, we are constrained to have some way to "interconvert" between them, but I don't know that it imposes any other constraints on the Rust unwind mechanism.
Yes I was referring there to “C with the Rust unwinding mechanism” and yes I feel differently about “C with native unwinding” since I don’t know of any constraints that this would impose on the Rust panic implementation. AFAICT we can always do a catch_unwind and then re-start unwinding using a different mechanism.
OK, I think we've generally agreed that "C with native unwinding" is the way to go.