seer VS kani

Nice, I just would have liked to get all these different verification tools combined under the same interface, just being different backends as drafted by the rust verification tools work of project oak: have "cargo verify" as common command and use common test annotations, allowing the same test to be verified with different backends or just fuzzed/proptested.

The model checking approach seems to be a bit limited regarding loops. There are also abstract interpreters, such as https://github.com/facebookexperimental/MIRAI, and symbolic executers, such as https://github.com/dwrensha/seer or https://github.com/GaloisInc/crucible.

Overall I believe this space would benefit from more coordination and focus on developing something that has the theoretical foundations to cover as many needs as possible and then make a user-friendly tool out of it that is endorsed by the Rust project similar to how Rust analyzer is the one language server to come.

This is also the backend for Kani - Amazon's formal verification tool for Rust.

https://github.com/model-checking/kani

Nice read! Rust has pushed, and will continue to push, the limits of practical, bare metal, memory safe languages. And it's interesting to think about what's next, maybe eventually there will be some form of practical theorem proving "for the masses". Lean 4 looks great and has potential, but it's still mostly a language for mathematicians. There has been some research on AI constructed proofs, which could be the best of both worlds because then the type checker can verify that the AI generated code/proof is indeed correct. Tools like Kani are also a step forward in program correctness.

Ease setup in Amazon Linux 2 by @adpaco-aws in #2833

Limit --exclude to workspace packages by @tautschnig in #2808

Here's a summary of what's new in version 0.38.0:

> those applications need the proof for correctness so that more dangerous code---say, what would need `unsafe` in Rust---can be safely added

There are actually already tools built for this very purpose in Rust (see Kani [1] for instance).

Formal verification has a serious scaling problem, so forming programs in such a way that there are a few performance-critical areas that use unsafe routines seems like the best route. I feel like Rust leans into this paradigm with `unsafe` blocks.

[1] - https://github.com/model-checking/kani

Enable concrete playback for failure of UB checks by @zhassan-aws in https://github.com/model-checking/kani/pull/2727

Change default solver to CaDiCaL by @celinval in https://github.com/model-checking/kani/pull/2557 By default, Kani will now run CBMC with CaDiCaL, since this solver has outperformed Minisat in most of our benchmarks. User's should still be able to select Minisat (or a different solver) either by using #[solver] harness attribute, or by passing --solver= command line option.

Add support for sysconf by feliperodri in #2557