Skip to content

Commit

Permalink
Unrolled build for rust-lang#125043
Browse files Browse the repository at this point in the history
Rollup merge of rust-lang#125043 - RalfJung:ref-type-safety-invariant, r=scottmcm

reference type safety invariant docs: clarification

The old text could have been read as saying that you can call a function if these requirements are upheld, which is definitely not true as they are an underapproximation of the actual safety invariant.

I removed the part about functions relaxing the requirements via their documentation... this seems incoherent with saying that it may actually be unsound to ever temporarily violate the requirement. Furthermore, a function *cannot* just relax this for its return value, that would in general be unsound. And the part about "unsafe code in a safe function may assume these invariants are ensured of arguments passed by the caller" also interacts with relaxing things: clearly, if the invariant has been relaxed, unsafe code cannot rely on it any more. There may be a place to give general guidance on what kinds of function contracts can exist, but the reference type is definitely not the right place to write that down.

I also took a clarification from rust-lang#121965 that is orthogonal to the rest of that PR.

Cc ```@joshlf``` ```@scottmcm```
  • Loading branch information
rust-timer authored May 22, 2024
2 parents 93e7cb8 + 7c76eec commit 6d6f92a
Showing 1 changed file with 8 additions and 5 deletions.
13 changes: 8 additions & 5 deletions library/core/src/primitive_docs.rs
Original file line number Diff line number Diff line change
Expand Up @@ -1476,14 +1476,17 @@ mod prim_usize {}
///
/// For instance, this means that unsafe code in a safe function may assume these invariants are
/// ensured of arguments passed by the caller, and it may assume that these invariants are ensured
/// of return values from any safe functions it calls. In most cases, the inverse is also true:
/// unsafe code must not violate these invariants when passing arguments to safe functions or
/// returning values from safe functions; such violations may result in undefined behavior. Where
/// exceptions to this latter requirement exist, they will be called out explicitly in documentation.
/// of return values from any safe functions it calls.
///
/// For the other direction, things are more complicated: when unsafe code passes arguments
/// to safe functions or returns values from safe functions, they generally must *at least*
/// not violate these invariants. The full requirements are stronger, as the reference generally
/// must point to data that is safe to use at type `T`.
///
/// It is not decided yet whether unsafe code may violate these invariants temporarily on internal
/// data. As a consequence, unsafe code which violates these invariants temporarily on internal data
/// may become unsound in future versions of Rust depending on how this question is decided.
/// may be unsound or become unsound in future versions of Rust depending on how this question is
/// decided.
///
/// [allocated object]: ptr#allocated-object
#[stable(feature = "rust1", since = "1.0.0")]
Expand Down

0 comments on commit 6d6f92a

Please sign in to comment.