I don’t think Rust’s ownership semantics are well-defined if you
longjmp either into or out of Rust code.
The thing that leaps to mind for me is the
Drop trait. The LLVM intrinsics have no knowledge of Rust’s drop flags, so traversing, or leaving a stack frame with
Droppable values in it using
longjmp will leak the associated resources, while entering a frame that way will cause any
Droppable values to be inappropriately
drop()ped without being initialized first.
If you’re careful to only ever
longjmp out of code that cannot have such values on the stack, and to only ever
longjmp into code prepared to be reentered in the middle in ways that aren’t formally possible in Rust, you might be able to get away with it anyways, though.
You could, of course, perform the moral equivalent of a
longjmp within your asm-language code to return to immediately inside of the call boundary, then return normally to Rust from there…