I'm writting a rust crate (for help writting R plugins with rust), since R uses SJLJ to deal with errors, when rust panic, I have to obtain a eh_personality function to unwind the stack and prevent memory leak before the error function (no_return) Rf_error(void*) is called.
I found it very difficult doing such things, there is only outdated crates (e.g., using intrinics::r#try to do a catch_unwind) and there is no doc for that strange function eh_personality.
The other function, such as __rust_drop_panic, __rust_foreign_exception are not difficult to implement, some other function such as __rust_panic_cleanup could be found easily by extern crate panic_unwind.
But, when I switch the eh_personality lang item to pub extern "C" fn eh_personality(){super::println!("eh_personality called");}, there is no unwind action and the memory leaks. There is no convenient method to obtain such function by extern a specific built-in crate, either.
Fortunately, I found the source code of that strange function located in std crate, thus I copied them into my crate.
But... Is it correct? Are there any better methods dealing with unwinding?
The personality function is language specific and the compiler specifies for each function individually which personality function to use in the unwind tables it generates. You should never have to override rust's personality function. And the correct definition of the rust personality function may change between rustc versions, just like all __rust_* functions.
It isn't clear what you are trying to do. It looks like you are writing a no_std library that requires unwinding (normally people set panic=abort for such libraries, but I can see why you might want unwinding). However, I can't see why you need this to be no_std, since you are making R plugins and I think it is unlikely R will run in any target that lacks the Rust standard library.
If you do need unwinding on no_std, then I found the unwinding crate, which offers pure Rust unwinding support and may suit your needs. Otherwise, I think you would need to link to OS-specific unwinding libraries.
The reason I choose a no_std crate is mainly for its fast compiling speed.
It takes ~40s to compile a simple demo with the old rextendr crate in its first run (with every optimization option (including lto) enabled), which annoying me, and this is the reason why I'm writting a new crate. If you only want to writting demos, disable the std crate will make the code compiles faster.
(with lto=true, linking std takes about 4s, but no-std only takes 1s, that's why I'm trying a no_std version.)
Although several second is meanless, I still want a faster crate.
why are you building release builds frequently enough that 40s compile time is annoying enough to build with no_std? if you want rapid iteration, that's what the dev profile is for.
the only time i think it makes sense to do a lot of release builds is when benchmarking.
You might be looking for dependency profiles that let you set optimization settings at the crate level Profiles - The Cargo Book - this let's you quickly iterate using a dev profile while still having well optimized dependencies.