mrustc VS miri

No, you don't. Existential proof: mrustc ignores lifetimes. Just flat out simply ignores. It changes some corner-cases related to HRBT, yet rustc compiled by mrustc works (that's BTW mrustc exist: to bootsrap the rustc compiler).

Incidentally C++ is the only way to bootstrap rust without rust today.

https://github.com/thepowersgang/mrustc

Well, there is mrustc[0], a Rust compiler that doesn't include a borrow-checker, so it's possible to compile (at least some versions of) Rust without a borrow checker, though it might not result in the most optimized code.

AFAIK there are some optimization like the infamous `noalias` optimization (which took several tries to get turned on[1]) that uses information established during borrow checking.

I'm also not sure what the relation with NLL (non-lexical lifetimes) is, where I would assume you would need at least a primitive borrow-checker to establish some information that the backend might be interested in. Then again, mrustc compiles Rust versions that have NLL features without a borrow-checker, so it's again probably more on the optimization side than being essential.

[0]: https://github.com/thepowersgang/mrustc

[1]: https://stackoverflow.com/a/57259339

Mrustc supports Rust 1.54.0 today

There are three. The official one, mrustc (no borrow checker, but can essentially compile the official rustc) and GCC (can't really compile anything substantial yet). Only rustc is production-ready though.

Otherwise you could try compiling to C using mrustc and going from there, but as mrustc is really only intended for compiler bootstrapping it won't be a fun experience. Mrustc mostly just assumes that the code you're compiling is valid, so you lose all the advantages of choosing Rust over C in the first place. It also targets x86-64 so the C it emits might need some work before it'll compile.

In fact, https://github.com/thepowersgang/mrustc compiles code without the need for a borrow checker :-)

Instead of an independent re-implementation, a small niche implementation whose only purpose is to bootstrap, like mrustc. Since its a much smaller scope, and only intended to work on known correct code, its much simpler and easier to do. It doesnt need to do any type or borrow checking or much of anything, because the rust source is already known to be correct/checked by itself.

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.

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.

Have you tried adding miri checks to see specific warnings it suggests? It should have some memory leak checks aswell. https://github.com/rust-lang/miri

Depends on what you mean by "better experience". What the article doesn't mention is the fact that you can still run into undefined behavior (including pointer aliasing) in C/C++/Zig and have your programs exhibit unexplainable weirdness, but you won't get any help from the language/compiler to figure out where it's coming from. In Rust you just run MIRI which tells you exactly where you have undefined behavior as long as you have at least one test which exercises the affected code path.