The C setjmp/longjmp APIs deallocate stack allocated objects in function stack frames without calling destructors. Code that uses these two APIs is safe iff when the setjmp is replaced with a catch_unwind and the longjmp is replaced with panic!, no destructors are run between the executing of the panic and after the catch_unwind when panic=unwind.
Sometimes one needs to pass Rust callbacks to C code that uses setjmp, and the Rust callback needs to call C code that uses longjmp: C(setjmp)->Rust->C(longjmp).
The Rust code in the middle needs to prove that no types implement Drop between all execution paths from a longjmp to a setjmp.
One coarse way to prove this would be by statically rejecting all Rust functions that contain types implementing Drop in their stack frames. Those Rust functions might need to call generic code, that might or might not satisfy this property depending on the concrete generic parameters. This ends up requiring generic code to be polymorphic about this property.
The C
setjmp/longjmpAPIs deallocate stack allocated objects in function stack frames without calling destructors. Code that uses these two APIs is safe iff when thesetjmpis replaced with acatch_unwindand thelongjmpis replaced withpanic!, no destructors are run between the executing of thepanicand after thecatch_unwindwhenpanic=unwind.Sometimes one needs to pass Rust callbacks to C code that uses
setjmp, and the Rust callback needs to call C code that useslongjmp: C(setjmp)->Rust->C(longjmp).The Rust code in the middle needs to prove that no types implement Drop between all execution paths from a
longjmpto asetjmp.One coarse way to prove this would be by statically rejecting all Rust functions that contain types implementing
Dropin their stack frames. Those Rust functions might need to call generic code, that might or might not satisfy this property depending on the concrete generic parameters. This ends up requiring generic code to be polymorphic about this property.