Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

References refer to allocated objects #116677

Merged
merged 7 commits into from
Jan 29, 2024
Merged
Changes from 6 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
19 changes: 19 additions & 0 deletions library/core/src/primitive_docs.rs
Original file line number Diff line number Diff line change
Expand Up @@ -1389,6 +1389,25 @@ mod prim_usize {}
/// work on references as well as they do on owned values! The implementations described here are
/// meant for generic contexts, where the final type `T` is a type parameter or otherwise not
/// locally known.
///
/// # Safety
///
/// For all types, `T: ?Sized`, and for all `t: &T` or `t: &mut T`, unsafe code may assume that
/// the following properties hold. Rust programmers must assume that, unless explicitly stated
/// otherwise, any Rust code they did not author themselves may rely on these properties, and that
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think I like all the text here, but one thing concerns me is that "did not author themselves" sounds to me like it could easily be interpreted as "it's ok to do this in your own code", and I'm not sure if that's the case. Have we made a decision on the validity rules for fat pointers?

@WaffleLapkin mentioned in triage that there might be static alignment rules ever for T: ?Sized (maybe even with future traits like rust-lang/rfcs#3319 ), so I think we want to make sure that &[Align8] can have a validity invariant of align-8 for the address part, at least?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, that the same thing probably comes up for size niches too. Would it ever be possible for there to be a statically-known min size for a DST, allowing a validity invariant on the range of the address as well? (Like how we could have a validity invariant that &i32 cannot be usize::MAX.)

I'll link to https://github.com/rust-lang/rfcs/pull/3204/files#diff-6c49cfff6f910d914acb2e9bfa78ad35155e6800b9114ef91e6e47c7db914b7cR97 here that wants to use a bunch of this kind of thing.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is only meant to put a lower bound of the safety invariant, but not fix the validity invariant at all. So this only says what you can assume about data coming on over an ABI boundary, but does not say anything about what you may do internally in your own code.

I'm open for suggestions for how to word this more clearly.

/// violating them may cause that code to exhibit undefined behavior.
///
/// * `t` is aligned to `align_of_val(t)`
/// * `t` is dereferenceable for `size_of_val(t)` many bytes
///
/// If `t` points at address `a`, being "dereferenceable" for N bytes means that the memory range
/// `[a, a + N)` is all contained within a single [allocated object].
///
/// Note that the precise validity invariants for reference types are a work in progress. In the
/// future, new guarantees may be added. However, the guarantees documented in this section will
/// never be removed.
joshlf marked this conversation as resolved.
Show resolved Hide resolved
///
/// [allocated object]: ptr#allocated-object
#[stable(feature = "rust1", since = "1.0.0")]
mod prim_ref {}

Expand Down
Loading