prusti-dev VS miri

> The overall goal would be to figure out classical error conditions like nill pointers deference.

> If I can figure out if a pointer will be nil in some execution branch, there is no reason why a computer cannot do the same.

Note, this is called flow-sensitive typing (also called type narrowing) and I think that typescript does it.

https://en.wikipedia.org/wiki/Flow-sensitive_typing

> I personally would see this as an human race level upgrades. Imagine feeding your code to a CI that spit back something like: "you will have a panic at line 156 when your input is > 4"

A model checker can do that!

See this

https://model-checking.github.io/kani/tutorial-kinds-of-fail...

Other techniques are also possible

https://github.com/viperproject/prusti-dev#quick-example

(Here I could link a lot of things, I just selected two Rust projects to illustrate)

This works better if you are able to provide contracts in your API that says which guarantees you provide. Alternatively, asserts are useful too.

You might be interested in the Prusti project, which statically checks for absence of reachable panics, overflows etc. It also allows user-defined specifications such as pre and post-conditions, loop body invariants, termination checking and so on.

https://github.com/viperproject/prusti-dev

This is called refinement types and prusti might be the project you saw.

But there's also a lot of exciting work around formal verification like Prusti.

prusti

Efforts: seL4, Project Everest, the Prossimo project of the ISRG, Let's Encrypt, and Prusti for the Rust language

Wow that sounds really cool! I'm not an expert but does that mean that one day you could implement dependend types or refinement types in Rust as a crate ? I currently only know of tools like: Flux Creusot Kani Prusti

Provenance is a dynamic property of pointer values. The actual underlying rules that a program must follow, even when using raw pointers and `unsafe`, are written in terms of provenance. Miri (https://github.com/rust-lang/miri) represents provenance as an actual value stored alongside each pointer's address, so it can check for violations of these rules.

Lifetimes are a static approximation of provenance. They are erased after being validated by the borrow checker, and do not exist in Miri or have any impact on what transformations the optimizer may perform. In other words, the provenance rules allow a superset of what the borrow checker allows.

There has been discussion of doing this with MIRI, which would be easier than all of rustc.

This issue has been fixed: https://github.com/rust-lang/miri/issues/2964

Actually, I've done more advanced tests with MIRI (see https://github.com/rust-lang/miri/issues/2920 for example) which allowed me to fix some issues. I've also made the code compatible with loom, but I didn't found the time yet to write and execute loom tests. That's on the TODO-list, and I need to track it with an issue too.

He is one of the big brains behind Miri, which is a interpreter that runs on the MIR (compiler representation between human code and asm/machine code) and detects undefined behavior. Super useful tool for language safety, pretty interesting on its own.

I would also run your tests in Miri (https://github.com/rust-lang/miri) to try to cover more bases.

You can run miri and it will tell you if the given run triggered any undefined behavior. It will not analyze it for every possible use of the code, but checking for the presence of this specific issue using it should be fairly simple.

If you do encounter a piece of code on which TB performs much worse than SB, do submit it as an issue! There was one recently and we massively improved TB performance on this case by improving garbage collection.