Also I made the whole Glossary alphabetical.

Could you make that a separate PR, for ease of reviewing?

Alright

• cleanup deferred for now
• Noted that noalias is an LLVM IR implementation detail that has a different idea of what aliasing is, but that it's a detail of LLVM-Rust, not really a properly of the Rust Abstract Machine.

Ah whatever, I think I will just do an editing pass and also define "Tag" while I am at it. ;) Thanks a lot @Lokathor !

I think I'm a bit late to this party, but how does the definition here interact with slices of ZSTs (#168)?

A span of memory is similar to how a slice works: there's a base byte address as well as a length in bytes.

One interesting side effect of these rules is that references and pointers to Zero Sized Types never alias each other, because their span length is always 0 bytes.

According to these rules, slices of ZSTs always have a span byte length 0 and thus never alias. But I'd argue that a and b in the following code do alias the same allocation, even though the allocation has a length of 0 bytes:

let foo = [(); 1337];
let a = &foo[..];
let b = &foo[..7];

According to these rules, slices of ZSTs always have a span byte length 0 and thus never alias.

That is correct, and actually explicitly stated further down in this PR.

But I'd argue that a and b in the following code do alias the same allocation, even though the allocation has a length of 0 bytes:

I'd argue you are wrong, then. ;) Also see rust-lang/rust-memory-model#44.
What is the benefit of adding a special case for ZST this way?

I think my misunderstanding here is that mutable references are highly underdocumented. The only "real" documentation of them I know of is the following part of the nomicon:

There are two kinds of reference:

• Shared reference: &
• Mutable reference: &mut

Which obey the following rules:

• A reference cannot outlive its referent
• A mutable reference cannot be aliased

That's it. That's the whole model references follow.

Reading through the linked issue, I understand that those are only necessary and not sufficient definitions. I was under the impression that they are sufficient and thus interpreted the noaliasing rule of ZSTs such that you can have multiple mutable references to the same ZST at the same time, which obviously is just wrong. I think I just need to split the meanings of "aliasing" and "references" in my brain.

You can think of there being arbitrarily many ZST "between" any two memory addresses, and references can point to those. So even if two ZST references point to the same location, they don't "overlap".

That pragmatic response is that aliasing is about figuring out if memory operations through one reference can be observed through the other reference, or if they can be freely reordered. But no memory access actually ever happens with a ZST reference.