Rollup merge of #129653 - RalfJung:addr-of-read-only, r=scottmcm

clarify that addr_of creates read-only pointers

Stacked Borrows does make this UB, but Tree Borrows does not. This is tied up with https://github.com/rust-lang/rust/issues/56604 and other UCG discussions. Also see [this collection of links](https://github.com/Rust-for-Linux/linux/pull/950#discussion_r1104759431) where rustc treats `addr_of!` as a "non-mutating use".

So, let's better be careful for now.
This commit is contained in:
Matthias Krüger 2024-09-05 19:43:47 +02:00 committed by GitHub
commit 85d15d292d
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194

View File

@ -2277,6 +2277,14 @@ fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result {
/// `addr_of!(expr)` is equivalent to `&raw const expr`. The macro is *soft-deprecated*;
/// use `&raw const` instead.
///
/// It is still an open question under which conditions writing through an `addr_of!`-created
/// pointer is permitted. If the place `expr` evaluates to is based on a raw pointer, then the
/// result of `addr_of!` inherits all permissions from that raw pointer. However, if the place is
/// based on a reference, local variable, or `static`, then until all details are decided, the same
/// rules as for shared references apply: it is UB to write through a pointer created with this
/// operation, except for bytes located inside an `UnsafeCell`. Use `&raw mut` (or [`addr_of_mut`])
/// to create a raw pointer that definitely permits mutation.
///
/// Creating a reference with `&`/`&mut` is only allowed if the pointer is properly aligned
/// and points to initialized data. For cases where those requirements do not hold,
/// raw pointers should be used instead. However, `&expr as *const _` creates a reference