Reducing Raw Pointer Footguns: Preventing Reference Aliasing Violations at Compile Time

fuji-184:

What kind of warning do you mean?

Warning in the literal “people warn each other about this” sense, not the “compiler warning” sense.

fuji-184:

And it would be better for this to become a compile time error rather than just a warning, because warnings do not stop UB code from compiling

If it were made into a clippy lint, if the analysis reliably catches UB with very few false positives, it could be made deny-by-default (resulting in a compilation error). Perhaps a second clippy lint with slightly broader analysis and more false positives could be warn-by-default.

fuji-184:

No dependencies are being pulled in because this is just pure Rust code plus a proc macro library

Don’t give too much trust to your AI. Pure Rust crates count as dependencies. Moreover, your proc macro pulls in a well-known crate commonly considered to be a “heavy” dependency, syn.

fuji-184:

The question is whether Clippy has enough context to fully understand Rust aliasing rules? If it does, then it could be worth trying

Yeah, I have no clue.

fuji-184:

It's like having a way to prevent data races at compile time so we don't need Miri.

Rust’s Send and Sync system is fantastic for safe code. But I think you severely overestimate how much is possible to check. When I make an unsafe concurrent data structure like a skiplist with lock-free reads, then forget relying on compile-time checks, forget relying on only Miri; I’m going to do exhaustive loom tests. (I’ll probably also start using shuttle for my next such project.)

The invariants of a structure like that are simply too complicated to be checked by the compiler. Sure, “the checks can’t be perfect” isn’t an argument to add no new checks, but…

fuji-184:

Rust's goal is to move as many errors as possible to compile time

More precisely, I’d say that “a major goal of Rust is to move as many errors as reasonably possible to compile time”. It is not a full formal verification system. Ergonomics, compiler performance, and no doubt many other factors influence whether Rust is willing to check for some class of errors. I’m fairly sure that “as many errors as possible” is “all of them”. But I worry that such a programming language might be fit for use only by mathematicians, and productivity would be quite low.

So, since Rust leaves some errors to runtime and some are not caught at all (which can include UB), yes, some part of the code gated behind unsafe will need careful manual reasoning. The advantage over C and C++ is (supposed to be) that the safety invariants of the code are precisely defined and need to be carefully checked only for unsafe operations.