{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreiaah7wrgvqme5lmdurhbj7dc4a57uuyyqgxfrlsh4hb7m2dlermuq",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3mlzpdp3cdnr2"
  },
  "path": "/t/reducing-raw-pointer-footguns-preventing-reference-aliasing-violations-at-compile-time/24301?page=2#post_29",
  "publishedAt": "2026-05-17T04:42:29.000Z",
  "site": "https://internals.rust-lang.org",
  "textContent": "fuji-184:\n\n> What kind of warning do you mean?\n\nWarning in the literal “people warn each other about this” sense, not the “compiler warning” sense.\n\nfuji-184:\n\n> 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\n\nIf 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.\n\nfuji-184:\n\n> No dependencies are being pulled in because this is just pure Rust code plus a proc macro library\n\nDon’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`.\n\nfuji-184:\n\n> The question is whether Clippy has enough context to fully understand Rust aliasing rules? If it does, then it could be worth trying\n\nYeah, I have no clue.\n\nfuji-184:\n\n> It's like having a way to prevent data races at compile time so we don't need Miri.\n\nRust’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.)\n\nThe 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…\n\nfuji-184:\n\n> Rust's goal is to move as many errors as possible to compile time\n\nMore 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.\n\nSo, 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.",
  "title": "Reducing Raw Pointer Footguns: Preventing Reference Aliasing Violations at Compile Time"
}