No-Panic Rust: A Nice Technique for Systems Programming

The approach at the end of declaring invariants to the compiler so the compiler can eliminate panics seems accidentally genius. You can now add the same invariants as panicking asserts at the end of each function, and the compiler will prove to you that your functions are upholding the invariants. And of course you can add more panicking asserts to show other claims to be true, all tested at compile time. You&#x27;ve basically built a little proof system.<p>Sure, Rust is hardly the first language to include something like that and adoption of such systems tends to be ... spotty. But if it was reliable enough and had a better interface (that preferably allowed the rest of your program to sill have panics) this might be very useful for writing correct software.

I&#x27;ve had an unpleasant amount of crashes with Rust software because people are way too quick to grab `panic!` as an out.<p>This was most shocking to me in some of the Rust code Mozilla had integrated into Firefox (the CSS styling code). There was some font cache shenanigans that was causing their font loading to work only semi-consistently, and that would outright crash this subsystem, and tofu-ify CJK text entirely as a result.<p>And the underlying panic was totally recoverable in theory if you looked at the call stack! Just people had decided to not Result-ify a bunch of falliable code.

&gt; fn check_invariant(&amp;self) { &gt; unsafe { assert_unchecked(self.ofs &lt; &gt; self.data.len()) } &gt; }<p>Is fundamentally unsound `check_invariant` needs to be unsafe as it doesn&#x27;t actually check the invariant but tells the compiler to blindly assume they hold. Should probably also be named `assume_invariant_holds()` instead of `check_invariant()`.

This seems to obviate a lot of Rust&#x27;s advantages (like a good std library). I wonder what it would take to write a nopanic-std library?<p>Panics really seem bad for composability. And relying on the optimzer here seems like a fragile approach.<p>(And how is there no -nopanic compiler flag?)

&gt; Unrecoverable<p>panics are very much designed to be recoverable at some well defined boundaries (e.g. the request handler of a web server, a thread in a thread pool etc.)<p>this is where most of it&#x27;s overhead comes from<p>you can use panic=abort setting to abort on panics and there is a funny (but unpractical) hack with which somewhat can make sure that no not-dead-code-eliminated code path can hit a panic (you link the panic-&gt;abort handler to a invalid symbol)

This website makes by browser freeze... No idea why. Not able to read the article.

OP sounds like they&#x27;d be very interested in Zig to tackle this particular problem. they&#x27;d get to a very similar place and not have to fight the language or the standard library to get there.

This blog post is very interesting, using Rust’s compiler optimizer as a theorem prover. This makes me wonder: are there any formal specifications on the complexity of this &quot;optimizer as theorem prover&quot;?<p>Specifically, how does it handle recursion? Consider, for example, the following function, which decrements a number until it reaches zero. At each step, it asserts that the number is nonzero before recursing:<p>fn recursive_countdown(n: u32) -&gt; u32 { assert!(n &gt; 0, &quot;n should always be positive&quot;); if n == 1 { return 1; } recursive_countdown(n - 1) }<p>Can the compiler prove that the assertion always holds and possibly optimize it away? Or does the presence of recursion introduce limitations in its ability to reason about the program?

Does anyone know if there&#x27;s an obvious reason that adding a `no_panic` crate attribute wouldn&#x27;t be feasible? It certainly seems like an &quot;obvious&quot; thing to add so I&#x27;m hesitant to take the obvious nerd snipe bait.

It should be possible to write a sanitizer which verifies no panic behavior on a call graph, just as you can to verify no blocking, or no races.

Why worry about the code size if the code size is up to the library consumer (through their choice of panic handler)? If the consumer worries about code size, then their application has a minimal panic handler. If the consuming application does not have a minimal panic handler, then it must not worry about code size?<p>Is there some context I&#x27;m missing here? Is this to be used from non-Rust applications for example?

Most people are using a prebuild standard library. That comes with the problem that it comes with the features it was build for. Most of the bloat around panic for example can be eliminated by just compiling the std library yourself. This is done via the `-Zbuild-std` flag.<p>Using this flag one than can use `panic_abort`. This will eliminate the unwinding part but would still give a &quot;nice&quot; printout on a panic itself. This reduces, in most cases, the mention bloat by a lot. Though nice printouts also cost binary space. For eliminating that `panic_immidiate_abort` exists.<p>But yeah the above is only about bloat and not the core goal to eliminate potential path&#x27;s in your program, that would lead to a panic condition itself.<p>Also currently building the std library yourself needs a nightly compiler. There is afaik work on bringing this to a stable compiler but how exactly is still work in progress.

Does Rust have something like a deep-codemodding macro that could be used to un-panic-fy an entire function etc. automatically?<p>Something like: Given a function, rewrite its signature to return a Result if it doesn&#x27;t already, rewrite each non-Resulty return site to a Some(), add a ? to every function call, then recurse into each called function and do the same.

While not as strict, you can filter lints by their description and apply a policy to your crate <a href="https:&#x2F;&#x2F;rust-lang.github.io&#x2F;rust-clippy&#x2F;rust-1.84.0&#x2F;index.html#&#x2F;panic" rel="nofollow">https:&#x2F;&#x2F;rust-lang.github.io&#x2F;rust-clippy&#x2F;rust-1.84.0&#x2F;index.ht...</a>

&gt; Protocol Buffers<p>Instead of serializing data (to disk, not the network), it would be much faster if Rust allowed us to allocate datastructures directly in an mmapped file, and allowed us to read back the data (basically patching the pointers so they become valid if the base address changed).

This page reliably crashes Chrome on my Android phone as a well as on my Ubuntu laptop.

Perhaps verus would be helpful to the op: <a href="https:&#x2F;&#x2F;github.com&#x2F;verus-lang&#x2F;verus">https:&#x2F;&#x2F;github.com&#x2F;verus-lang&#x2F;verus</a>

&gt; not panic&#x27;ing (or at least not doing it so bluntly at a low level) can at the very least help with debugging.<p>Wouldn’t panicking asap make debugging easier?

&gt; If we are trying to port a C library to Rust, we really do not want to introduce panics in the code, even for unusual error condition.<p>&quot;We&#x27;d much rather like to make library to corrupt the memory of the rest of the application and generally make the demons fly out of the users&#x27; noses, as it does when written in C&quot;?<p>I believe implementations of C stdio also can abort on program startup if somehow the pthreads&#x27; locking mechanism is broken (or if e.g. fcntl(2)&#x2F;open(2) keeps returning -1), Rust is not that unique in this regard.

This website panics on my iOS version 18.1.1 in Safari. Is anyone else having issues on mobile?

Funnily enough this website hard-crashes Android Chrome and DuckDuckGo browsers after loading.

This seems..absurd for a programming language with goals like Rust. Why isn&#x27;t this a compiler option? Just set -nopanics and the compiler errors and flags anything which is pulling in a panic at the very least?