no-panic VS rust

I discovered a crate called no_panic that prevents a function from compiling, unless the compiler can proof that this function can't panic.

/u/dtolnay has a no-panic macro, I don't know its limitations but in older comments they note it pretty much has to be used in release mode, as there are lots of panic codepaths which get optimised out.

'Hacks' such as https://github.com/dtolnay/no-panic, https://crates.io/crates/no-panics-whatsoever that ensure any calls to panic handling will result in link errors. Not really reliable in terms of being able to abort instead, but a possible tool.

nope. Unfortunately, no mainstream language has this yet. We need an Algebraic effects typesystem to do this properly. There are a few temporary band-aid solutions like https://github.com/dtolnay/no-panic

This kind of already exists in the form of #[no_panic] [1]?

> If the function does panic (or the compiler fails to prove that the function cannot panic), the program fails to compile with a linker error that identifies the function name.

1: https://github.com/dtolnay/no-panic

I really think that Rust needs an official #[no_panic] macro that can validate these sort of things (like dtolnay’s crate, I’m not sure why it was archived)

Because it's convenient and familiar to most programmers. Not providing bounds-checked indexing makes some kinds of code very hard to write.

But note his problem also happens with integer division.

In Rust, a[x] on an array or vec is really a roughly a shortand for a.get(x).unwrap() (with a different error message)

Likewise, a / b on integers is a kind of a shortand for a.checked_div(b).unwrap()

The thing is, if the index ever is out of bounds, or if the denominator is zero, the program has a bug, 100% of time. And if you catch a bug using an assertion there is seldom anything better than interrupting the execution (the only thing I can think of is restarting the program or the subsystem). If you continue execution past a programming error, you may sometimes corrupt data structures or introduce bizarre, hard to debug situations.

Doing a pattern match on a.get(x) doesn't help because if it's ever None (and your program logic expects that x is in bounds) then you are kind of forced to bail.

The downside here is that we aren't catching this bug at compile time. And it's true that sometimes we can rewrite the program to not have an indexing operation, usually using iterators (eliding the bounds check will make the program run faster, too). But in general this is not possible, at least not without bringing formal methods. But that's what tests are for, to ensure the correctness of stuff type errors can't catch.

Now, there are some crates like https://github.com/dtolnay/no-panic or https://github.com/facebookexperimental/MIRAI that will check that your code is panic free. The first one is based on the fact that llvm optimizations can often remove dead code and thus remove the panic from a[x] or a / b - if it doesn't, then compilation fails. The second one employs formal methods to mathematically prove that there is no panic. I guess those techniques will eventually be ported to the kernel even if panics happen differently there (by hooking on the BUG mechanism or whatever)

Hmm, yeah as you mentioned, looks like a surprising amount of stuff is already done in the rust for the linux kernel project: https://github.com/Rust-for-Linux/linux/tree/rust/rust/. It's also MIT/Apache licensed, but I was expecting gpl, so I can actually use it. It's still a lot to trim down on, so might be easier to just build up as needed. Additionally I just saw /u/dtolnay's #[no_panic] attribute which at least makes it a compiler error if it's accidentally done.

Obviously, in bare metal systems, in the kernel, etc, you always want to use the second style. In this patch series, the first type had been stubbed out to panic, but Linus doesn't want any chance of panicking, he wants it to be a compile time error if anyone tries to call these methods from within the kernel, for example by not providing the symbols and failing to link if someone did try to use them. There is already precedent for doing that in the Rust ecosystem, so it's planned to do that in this patch series, but the authors hadn't gotten to that yet.

If you haven't dipped your touch-typing fingers into Rust yet, you really owe it to yourself. Rust is a modern programming language with features that make it suitable not only for systems programming -- its original purpose, but just about any other environment, too; there are frameworks that let your build web services, web applications including user interfaces, software for embedded devices, machine learning solutions, and of course, command-line tools. Since a custom GitHub Action is essentially a command-line tool that interacts with the system through files and environment variables, Rust is perfectly suited for that as well.

Here's an example of someone citing a disagreement between CRT and shell32:

https://github.com/rust-lang/rust/issues/44650

This in addition to the Rust CVE mentioned elsewhere in the thread which was rooted in this issue:

https://blog.rust-lang.org/2024/04/09/cve-2024-24576.html

Here are some quick programs to test contrasting approaches. I don't have examples of inputs where they parse differently on hand right now, but I know they exist. This was also a problem that was frequently discussed internally when I worked at MSFT.

    #include 

> instead of choosing a certain numbered version of the random library (if I remember correctly) I let cargo download the latest version which had a completely different API.

Yeah, they didn't follow the instructions and got burned. I still think that multiple things went wrong simultaneously for that experience. I wonder if more prevalent uses of `#[doc(alias = "name")]` being leveraged by https://github.com/rust-lang/rust/pull/120730 (which now that I check only accounts for methods and not functions, I should get on that!) so that when changing APIs around people at least get a slightly better experience.

Almost fixed the compiler: https://github.com/rust-lang/rust/pull/123325

Rust: A secure, efficient, and modern programming language (omitting ten thousand words). You can simply follow the installation instructions provided on the official website.

Recently did something similar in Rust but for generating SVGs. We've adopted it for snapshot testing of cargo and rustc's output. Don't have a good PR handy for showing Github's rendering of changes in the SVG (text, side-by-side, swiping) but https://github.com/rust-lang/rust/pull/121877/files has newly added SVGs.

To see what is supported, see the screenshot in the docs: https://docs.rs/anstyle-svg/latest/anstyle_svg/

We strongly believe in Rust as a powerful language for building production-grade software, especially for systems like ours that run alongside Kubernetes.

The above Assert<{N % 2 == 1}> requires #![feature(generic_const_exprs)] and the nightly toolchain. See https://github.com/rust-lang/rust/issues/76560 for more info.