Prevent panics statically

[joshlf]

Issues like #200 demonstrate that the compiler is sometimes not smart enough to optimize out panics that we can prove statically won't happen. It would be good if we could:

• Refactor to only use operations which don't include panicking in their call graph
• Validate this in CI

See also #325, #1125

Mentoring instructions

• Easy steps
  • Create a new step in this CI job that runs Red Pen on zerocopy, only running the step under if: matrix.crate == 'zerocopy' && matrix.toolchain == 'nightly'
  • Annotate as many functions as possible with #[redpen::dont_panic]
• Medium to hard (depending on the code): Refactor as much code as possible to remove all panics

[jettr]

Here is a discussion on another project about having a no panic policy with some good information: https://github.com/orgs/tpm-rs/discussions/5

I think it could help the zerocopy library if it were interested in some automated CI checks to ensure no panics are present in "tier 1" tool chains.

[joshlf]

Awesome, thanks for that breadcrumb! I'd like to go even further than that, and ensure that panics aren't just optimized out, but never emitted in the first place. Do you know if that technique would work in conjunction with opt-level = 0, and would that suffice to guarantee that we're never emitting panics? I want to make sure we don't get into the situation in #200 in which panics are optimized out in a toy example but not in a larger application.

[jettr]

I like the idea of using opt-level=0 for the "tier 1" tool chains that CI checks against to ensure there are no panics. I don't know of a way to ensure panics are never emitted with 100% certainty though. I think your idea is about as close as you can get with currently tooling.