Description
I find the documentation about what libcore depends on a bit confusing right now. I'm trying to make my #[no_std]
crate compile after a year on inactivity for context.
Now firstly, this section describes several symbols, but is the actual symbol name relevant (ignoring memcpy
/memset
/etc)? Or do we only care about the existence of some function labeled with the appropriate attribute? The distinction between symbol name and the associated lang attribute is confusing here.
rust_begin_panic - This function takes four arguments, a fmt::Arguments, a &'static str, and two u32's. These four arguments dictate the panic message, the file at which panic was invoked, and the line and column inside the file. It is up to consumers of this core library to define this panic function; it is only required to never return. This requires a lang attribute named panic_impl.
It appears that the #[lang="panic_impl"]
mentioned is already declared in libcore/panicking.rs
. It appears that this should refer to #[lang = "panic_fmt"]
instead, which is what libcore
users formerly had to declare but is now implicitly declared by by the new #[panic_handler]
. Rustc will complain about missing a #[panic_handler]
currently. So this section should probably be updated to refer to #[panic_handler]
instead.
rust_eh_personality - is used by the failure mechanisms of the compiler. This is often mapped to GCC's personality function, but crates which do not trigger a panic can be assured that this function is never called. The lang attribute is called eh_personality.
It should probably be mentioned that #[lang="eh_personality"]
seems only necessary if panic=unwind
. Additionally should perhaps mention _Unwind_Resume
as well (which theoretically is only necessary for panic=unwind
builds but can erroneously be required for panic=abort opt-level=0
builds see #53301). There's actually more of these eh
functions that should be perhaps mentioned depending on your target. The subtleties are explained in libpanic_unwind
and libpanic_abort
.
Along the same lines, the docs of liballoc
should probably also mention #[alloc_error_handler]
(see #51540).
I can try writing up a draft or PR but wanted to get feedback first.