Connor Horman

SEH rules are indeed nice and consistent, but we aren't ever going to have a world where they're the only rules. > don't have as strong opinions on how C++...

> Don't we expose handlers via std::panic::catch_unwind already? My expectation is that at least in some cases I will be applying that to the body of every extern "C" exposed...

> One way to guarantee the behaviour that you want is to make every cleanup landing pad a (catching) handler instead. But the unwinder ABI mandates that if you report...

> I'm okay with making concessions when foreign frames or foreign exceptions are involved. But if a panic in the "naive" semantics (or in phase 1 unwind) never "sees" a...

I think @rust-lang/opsem may want to have a look at this as well, since it alters the AM behaviour of a language primitive (that would presumably have a corresponding Minirust...

Speaking as an expert in unwinding, beyond just "System Unwinds via an unsupported unwinding method", which I presume is just UB *per se* when it enters rust code, there shouldn't...

If someone, for example, called into MinGW code using SJLJ exceptions from MinGW compiled to use SEH, it wouldn't be able to interact with the exception at all (unless you...

> Sorry, what's "it" here? The Rust standard library compiled for MinGW? Yes - assuming its compiled to use SEH rather than SJLJ (should be the default without a switch...

> I, at least, fully expect us to have some way of writing alignment-obeying raw pointers in Rust in some way. If nothing else, slice::Iter is less good than it...

> We were curious in our discussions, does this RFC represent an existing T-opsem consensus? It does not represent any FCP done by T-opsem, which is why I've included them...