Add extern specs for all core functions used by ring buffer

[ninehusky]

Adds no_panic specs for the following functions:

core::slice::<impl [T]>::len: 9
core::num::<impl usize>::saturating_sub: 1
core::slice::<impl [T]>::split_at: 1
core::slice::index::<impl core::ops::Index<I> for [T]>::index: 2
core::ops::Fn::call: 1
core::ops::FnMut::call_mut: 1

[enjhnsn2]

Mostly looks good. Specs appear to be sound, but are currently trusted, but it would be good to at least attempt to verify them at some point.

[enjhnsn2]

why is this not just #[flux::no_panic]?

[ninehusky]

@nilehmann deferring to you for a smarter explanation. From what I remember, this has to do with Rust's mechanism for attaching attributes to modules? There's something about #[no_panic] becoming a "macro within a macro" which causes issues when showing up as a module annotation?

[nilehmann]

Since this is a test, this is actually not needed, because we never run rustc directly on tests. When using this for real, you can't write flux::no_panic directly because during normal compilation, rustc will complain about flux::no_panic not existing.

[enjhnsn2]

wait, but you can do flux_rs::no_panic, correct? Isn't flux_rs the standard way to invoke preconditions/postconditions?

[nilehmann]

Yes and no. For this particular example, flux_rs::no_panic would work, but it won't work for file module declaration (the common version of declaring modules), i.e., the following doesn't work.

#[flux_rs::no_panic]
mod my_module;

[enjhnsn2]

echo above comment about this being #[flux::no_panic]

[enjhnsn2]

#[flux::no_panic]

[ninehusky]

@enjhnsn2 @nilehmann are we good to punt the conversation re: cfg_attr(flux, no_panic) to a different PR? if so, this one is ready for review.

[nilehmann]

@enjhnsn2 @nilehmann are we good to punt the conversation re: cfg_attr(flux, no_panic) to a different PR? if so, this one is ready for review.

That part is already merged so I don't know why we were discussing it at all here 😅

[ninehusky]

OK, marking this ready for review then. I think the gh-pages step in CI is failing on this branch, but the last PR may have fixed that?

[nilehmann]

@ninehusky LGTM. Can you rebase and push to verify CI is green after #1382

[ninehusky]

@nilehmann done!