External Publication
Visit Post

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

Rust Internals [Unofficial] May 17, 2026
Source

What kind of warning do you mean? Because none of the code containing aliasing violations that I posted in the replies produces any warning from the compiler. 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

Having safety mechanisms that catch mistakes at compile time is better than only deeply studying unsafe Rust, because there is no guarantee that someone will immediately understand everything and never make mistakes afterward. That is similar to saying manually reasoning about C and C++ is better than having compile time safety checks that catch mistakes when they slip through. I do not understand how manual reasoning, which is highly prone to human error, could suddenly be considered better than compile time errors

No dependencies are being pulled in because this is just pure Rust code plus a proc macro library, which is we already uses the proc macro library when we uses the built in proc macros in Rust such as #[derive()], #[inline], #[test], and others

The question is whether Clippy has enough context to fully understand Rust aliasing rules? If it does, then it could be worth trying. But compile time errors are still preferable to warnings because this involves UB. As for Miri, I already answered that in my previous reply yesterday :]

Rust's goal is to move as many errors as possible to compile time, that’s the whole reason we have the borrow checker, to prevent mistakes at compile time. One aspect of this now is gradually giving unsafe Rust better ways to prevent mistakes, specifically regarding raw pointer to reference conversions that violate aliasing rules in this case. It's like having a way to prevent data races at compile time so we don't need Miri. If something can be checked at compile time, it's better than relying on Miri, because Miri needs to trigger every execution path to achieve 100% coverage, which is time consuming for large codebases. If there's a massive code update, we'd also need a massive update to the tests to ensure they run and maintain 100% coverage. With compile time checks, none of that is necessary. This is why Rust's advantage as a language with extensive compile time checks is so significant

Discussion in the ATmosphere

Loading comments...