Maybe?
Compare doc.rust-lang.org/nomicon/what-u, ralfj.de/blog/2020/12/1 and the papers on clang. What I study is C++, not Rust, but the Rust list doesn't look too convincing, assuming Ralf is right (which seems the most likely thing).
Conversation
Rust doesn't do TBAA and doesn't really need it due to the &T and &mut T restrictions so that's a lot of complexity that's avoided. It doesn't have the pointer provenance rules but LLVM doesn't really document what they do and my generic wording was lost when they updated it.
2
2
(generic wording? Do you have a link to the original, correct docs as you wrote them?)
1
The list there is almost the same as my original list but someone declared it complete/exhaustive when it originally didn't claim that, and the part about aliasing was ruined. Whoever replaced that seemed to miss a lot of the point. Not my problem to resolve though.
1
1
LLVM considers NoAlias to be about lack of memory dependencies between types. That means &T for types without interior mutability (which has to be declared) is NoAlias in the LLVM sense.
Also, that list is clearly missing the rules about immutability, among various other things.
1
Rust's rules for UB in unsafe code will definitely be a lot simpler than C and it doesn't have UB in safe code.
I strongly dislike the style that the documentation was remade into and part of that is it deliberately eschews accuracy in favor of being amusing and comforting.
1
1
It was originally worded like a specification and was called a language reference. It was supposed to be a serious document defining the language, not a tutorial.
Okay, here, look at this instead:
doc.rust-lang.org/stable/referen
This is the proper documentation, not that thing.
2
1
(FWIW, your link is the documentation I remember on what's considered UB. I've brought up before on here that I don't care for the whimsiness of the Rustnomicon.
But outside of limited contexts like this one, criticizing the tone of that document leads to... issues.)
1
I have serious issues with one of the main people originally responsible for it and they were the main reason that I became increasingly frustrated/disenchanted with the project and decided to resign from it and move on.
1
Taking stuff I made (code, docs) and ruining it while taking full credit for it is part of that, but a pretty small part overall. Anyway, probably best not to think too much about it. I like Rust quite a lot as a language and that's why I contributed a ton to it... but...
2
... I had quite major issues with how it was developed, how developers outside Mozilla were treated at the time (i.e. myself) and my criticism of design issues and approaches to docs/implementation/designs were taken very personally and were responded to in underhanded ways.