Skip to content

stabilize size_of_val_raw, align_of_val_raw, Layout::for_value_raw #157572

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.

Sign up for GitHub

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

Open
RalfJung wants to merge 3 commits into
base: main
Choose a base branch
from
+47 −50
Open

stabilize size_of_val_raw, align_of_val_raw, Layout::for_value_raw #157572

Show file tree
Hide file tree
Changes from 2 commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
244ab22
stabilize size_of_val_raw, align_of_val_raw, Layout::for_value_raw
RalfJung Jun 7, 2026
398e301
make it explicit that the extern type behavior is unstable
RalfJung Jun 17, 2026
0d9ecb8
don't repeat the safety invariant
RalfJung Jul 8, 2026
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
1 change: 0 additions & 1 deletion library/alloc/src/lib.rs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -140,7 +140,6 @@
#![feature(io_const_error_internals)]
#![feature(iter_advance_by)]
#![feature(iter_next_chunk)]
#![feature(layout_for_ptr)]
#![feature(legacy_receiver_trait)]
#![feature(likely_unlikely)]
#![feature(local_waker)]
Expand Down
31 changes: 20 additions & 11 deletions library/core/src/alloc/layout.rs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -230,24 +230,33 @@ impl Layout {
///
/// - If `T` is `Sized`, this function is always safe to call.
/// - If the unsized tail of `T` is:
/// - a [slice], then the length of the slice tail must be an initialized
/// - a [slice] `[U]` or `str`, then the length of the slice tail must be an initialized
/// integer, and the size of the *entire value*
Comment thread
RalfJung marked this conversation as resolved.
Outdated
/// (dynamic tail length + statically sized prefix) must fit in `isize`.
/// For the special case where the dynamic tail length is 0, this function
/// is safe to call.
/// - a [trait object], then the vtable part of the pointer must point
/// to a valid vtable for the type `T` acquired by an unsizing coercion,
/// and the size of the *entire value*
/// (dynamic tail length + statically sized prefix) must fit in `isize`.
/// - an (unstable) [extern type], then this function is always safe to
/// call, but may panic or otherwise return the wrong value, as the
/// extern type's layout is not known. This is the same behavior as
/// [`Layout::for_value`] on a reference to an extern type tail.
/// - otherwise, it is conservatively not allowed to call this function.
// NOTE: the reason this is safe is that if an overflow were to occur already with size 0,
// then we would stop compilation as even the "statically known" part of the type would
// already be too big (or the call may be in dead code and optimized away, but then it
// doesn't matter).
/// - a [trait object] `dyn Trait`, then the vtable part of the pointer must point
/// to a valid vtable for `Trait`, and the size
/// of the *entire value* (dynamic tail length + statically sized prefix)
/// must fit in `isize`.

@Mark-Simulacrum Mark-Simulacrum Jun 7, 2026 •
edited by rustbot
Loading

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

We document that the first part here ("vtable part of the pointer must point to a valid vtable") is a validity invariant for raw pointers (https://doc.rust-lang.org/nightly/reference/behavior-considered-undefined.html#r-undefined.validity.wide).

For obtaining a Layout, it makes sense to me that we can't exceed isize. However, I'm wondering if we want / will want a safe version of this function, that checks that you haven't exceeded isize. It seems like that's eminently possible since essentially the UB here is from doing an unchecked_add on the two involved sizes. I guess users will probably be able to do that themselves in the future via std::ptr::metadata (safe) and then checked_add of any sized prefix and the DynMetadata::size_of (safe). Maybe we know enough to stabilize at least some of the metadata surface area too...

View changes since the review

@RalfJung RalfJung Jun 7, 2026 •
edited
Loading

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

We document that the first part here ("vtable part of the pointer must point to a valid vtable") is a validity invariant for raw pointers

Yes. So it is technically redundant. It still seems worth repeating? It is dangerous to rely on validity invariants are a precondition since validity invariants may become weaker in future versions of Rust.

I'm wondering if we want / will want a safe version of this function, that checks that you haven't exceeded isize.

Maybe we do, but I don't think that has to be part of this stabilization.
In terms of how that would impact this stabilization, I guess the point is that maybe the functions we are stabilizing here should be called size_of_val_unchecked or size_of_val_raw_unchecked then?

@Mark-Simulacrum Mark-Simulacrum Jun 7, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Agreed on all points -- I think the impact on naming is the only thing for this stabilization.

@CAD97 CAD97 Jun 8, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

I agree that we want (to at least hold the space for) a safe option with checked overflow for MetaSized types. But since a requirement for being safe is specifically that the data pointer part doesn't matter, a part of me feels like the API for such shouldn't even be given the data part of the address, but only the metadata.

e.g. the API name in my head takes the shape Layout::with_metadata::<T>(<T as Pointee>::Metadata) -> Self.

@RalfJung RalfJung Jun 9, 2026 •
edited
Loading

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

The function name discussion should probably happen on the tracking issue as that's where libs-api will do their FCP.

@RalfJung RalfJung Jul 7, 2026

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

This way, caller of this function doesn't need to justify and this is implied by the type.

If we weaken the validity requirement in the future, the caller has something to justify.

Formally speaking, removing this text doesn't even change much, since talking e.g. about the integer value in the slice metadata implicitly imposes an initialization requirement. Every single time the docs talk about the value of an integer, they implicitly say "the integer is initialized and ...". Whatever code calls this has to argue why the value of the metadata satisfies the precondition, which means it has to argue that the value even exists, i.e., that it is initialized. So I can't think of any safety comments that would be simplified by this.

@nbdd0121 nbdd0121 Jul 7, 2026 •
edited
Loading

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

When a raw pointer exists in the first place, it would have implied the metadata already exists and is valid (and of course that implies initialized). For the slice case you even have the safe .len() method to access it, and for vtables, you can make use of the vtable by performing a trait upcasting. These are API/language features that make use of these invariants already, so it's not like the invariant can go away, we can at most weaken it from validity to safety invariant.

@RalfJung RalfJung Jul 8, 2026 •
edited
Loading

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

I am quite concerned about implicitly relying on external invariants here. We have been bitten by this in the past and we should learn from our mistakes. At the same time apparently many people find it confusing to repeat those currently redundant external invariants. No idea how to satisfy both of these at the same time -- any ideas?

It sounds like you are suggesting we shorten the entire thing to just this:

///     - a [slice] `[U]`, `str`, or a [trait object] `dyn Trait`, then the size of the *entire value*
///       (dynamic tail length + statically sized prefix) must fit in `isize`.
///       For the special case where the dynamic tail length is 0, this function
///       is safe to call.

But then how do we protect against #138351 -style problems?

@ojeda ojeda Jul 8, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

It sounds like you are suggesting we shorten the entire thing to just this:

Yes, that is what I meant, i.e. I was expecting safety requirements to not state conditions that are "impossible" to begin with. Otherwise, it can immediately make a reader wonder what one is missing, i.e. how that situation could happen to begin with (and, worse, wonder if one may have had bugs elsewhere due to such a misunderstanding and so on). Of course, from the point of view of an expert, it is likely obvious that it is redundant, but if one is not 100% sure that is the case, then it can be quite confusing.

Regarding the risk of updating a definition and not these conditions, I guess one could attempt to "tag" the functions that implicitly need to rely on a particular invariant (with an attribute or similar), so that one can force a review of those when the definition changes. I guess it could help other analysis too, but I imagine it can be a ton of work to set up. I always wondered how upstream actually handled such changes and kept track of everything, to be honest!

Having said that, the original problem above, i.e. the one for the reader, is really just to know whether it is redundant or not. Thus it may just be fine to keep them inline but at least somehow "highlight" that they are redundant -- that is why I suggested the footnote perhaps with a link to the invariant or similar. (It may also have some value as a low-tech, coarse tag to grep for, i.e. the point above, but less fancy.)

@RalfJung RalfJung Jul 8, 2026

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

Thinking about it some more, there is a key difference to #138351 -- as you said, we can view this as relying on the safety invariant of raw ptr metadata. That one isn't properly documented but it's also not at liberty to change -- and it implicitly is a precondition for every function that doesn't say otherwise.

/// - No other kind of unsized tail currently exists that satisfies the trait bounds for this
/// function. If more kinds of unsized tails get introduced in the future, the documentation
/// of this function will have to be extended before it can be used for such types.
///
/// Here, *unsized tail* refers to the type obtained by recursively descending through the last
/// field of a tuple or struct until we arrived at a built-in unsized type.
Comment on lines +245 to +246

@Darksonn Darksonn Jul 8, 2026 •
edited by rustbot
Loading

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Tuples with unsized tails were removed from the language in #137728.

View changes since the review

@Darksonn Darksonn Jul 8, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Errr ... actually forget about that. We just removed the coercion and the promise that (i32, i32) and (i32, dyn Send) have compatible layouts, but (i32, dyn Send) is still technically a type that exists in the language.

So forget about this comment.

///
/// As a consequence of these rules, it is the case that whenever it is allowed to convert `val`
/// into a shared reference, then it is also allowed to invoke this function.
///
/// [trait object]: ../../book/ch17-02-trait-objects.html
/// [extern type]: ../../unstable-book/language-features/extern-types.html
#[unstable(feature = "layout_for_ptr", issue = "69835")]
#[stable(feature = "layout_for_ptr", since = "CURRENT_RUSTC_VERSION")]
#[rustc_const_stable(feature = "layout_for_ptr", since = "CURRENT_RUSTC_VERSION")]
#[must_use]
#[inline]
pub const unsafe fn for_value_raw<T: ?Sized>(t: *const T) -> Self {
Expand Down
54 changes: 33 additions & 21 deletions library/core/src/mem/mod.rs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -422,8 +422,8 @@ pub const fn size_of_val<T: ?Sized>(val: &T) -> usize {
/// This function is only safe to call if the following conditions hold:
///
/// - If `T` is `Sized`, this function is always safe to call.
/// - If the unsized tail of `T` is:
/// - a [slice], then the length of the slice tail must be an initialized
/// - If the *unsized tail* of `T` is:
/// - a [slice] `[U]` or `str`, then the length of the slice tail must be an initialized
/// integer, and the size of the *entire value*
/// (dynamic tail length + statically sized prefix) must fit in `isize`.
/// For the special case where the dynamic tail length is 0, this function
Expand All @@ -432,15 +432,19 @@ pub const fn size_of_val<T: ?Sized>(val: &T) -> usize {
// then we would stop compilation as even the "statically known" part of the type would
// already be too big (or the call may be in dead code and optimized away, but then it
// doesn't matter).
/// - a [trait object], then the vtable part of the pointer must point
/// to a valid vtable acquired by an unsizing coercion, and the size
/// - a [trait object] `dyn Trait`, then the vtable part of the pointer must point
/// to a valid vtable for `Trait`, and the size
/// of the *entire value* (dynamic tail length + statically sized prefix)
/// must fit in `isize`.
/// - an (unstable) [extern type], then this function is always safe to
/// call, but may panic or otherwise return the wrong value, as the
/// extern type's layout is not known. This is the same behavior as
/// [`size_of_val`] on a reference to a type with an extern type tail.
/// - otherwise, it is conservatively not allowed to call this function.
/// - No other kind of unsized tail currently exists that satisfies the trait bounds for this
/// function. If more kinds of unsized tails get introduced in the future, the documentation
/// of this function will have to be extended before it can be used for such types.
///
/// Here, *unsized tail* refers to the type obtained by recursively descending through the last
/// field of a tuple or struct until we arrived at a built-in unsized type.
///
/// As a consequence of these rules, it is the case that whenever it is allowed to convert `val`
/// into a shared reference, then it is also allowed to invoke this function.
///
/// [`size_of::<T>()`]: size_of
/// [trait object]: ../../book/ch17-02-trait-objects.html
Expand All @@ -449,7 +453,6 @@ pub const fn size_of_val<T: ?Sized>(val: &T) -> usize {
/// # Examples
///
/// ```
/// #![feature(layout_for_ptr)]
/// use std::mem;
///
/// assert_eq!(4, size_of_val(&5i32));
Expand All @@ -460,7 +463,8 @@ pub const fn size_of_val<T: ?Sized>(val: &T) -> usize {
/// ```
#[inline]
#[must_use]
#[unstable(feature = "layout_for_ptr", issue = "69835")]
#[stable(feature = "layout_for_ptr", since = "CURRENT_RUSTC_VERSION")]
#[rustc_const_stable(feature = "layout_for_ptr", since = "CURRENT_RUSTC_VERSION")]
pub const unsafe fn size_of_val_raw<T: ?Sized>(val: *const T) -> usize {
// SAFETY: the caller must provide a valid raw pointer
unsafe { intrinsics::size_of_val(val) }
Expand Down Expand Up @@ -596,28 +600,35 @@ pub const fn align_of_val<T: ?Sized>(val: &T) -> usize {
///
/// - If `T` is `Sized`, this function is always safe to call.
/// - If the unsized tail of `T` is:
/// - a [slice], then the length of the slice tail must be an initialized
/// - a [slice] `[U]` or `str`, then the length of the slice tail must be an initialized
/// integer, and the size of the *entire value*
/// (dynamic tail length + statically sized prefix) must fit in `isize`.
/// For the special case where the dynamic tail length is 0, this function
/// is safe to call.
/// - a [trait object], then the vtable part of the pointer must point
/// to a valid vtable acquired by an unsizing coercion, and the size
// NOTE: the reason this is safe is that if an overflow were to occur already with size 0,
// then we would stop compilation as even the "statically known" part of the type would
// already be too big (or the call may be in dead code and optimized away, but then it
// doesn't matter).
/// - a [trait object] `dyn Trait`, then the vtable part of the pointer must point
/// to a valid vtable for `Trait`, and the size
/// of the *entire value* (dynamic tail length + statically sized prefix)
/// must fit in `isize`.
/// - an (unstable) [extern type], then this function is always safe to
/// call, but may panic or otherwise return the wrong value, as the
/// extern type's layout is not known. This is the same behavior as
/// [`align_of_val`] on a reference to a type with an extern type tail.
/// - otherwise, it is conservatively not allowed to call this function.
/// - No other kind of unsized tail currently exists that satisfies the trait bounds for this
/// function. If more kinds of unsized tails get introduced in the future, the documentation
/// of this function will have to be extended before it can be used for such types.
///
/// Here, *unsized tail* refers to the type obtained by recursively descending through the last
/// field of a tuple or struct until we arrived at a built-in unsized type.
///
/// As a consequence of these rules, it is the case that whenever it is allowed to convert `val`
/// into a shared reference, then it is also allowed to invoke this function.
///
/// [trait object]: ../../book/ch17-02-trait-objects.html
/// [extern type]: ../../unstable-book/language-features/extern-types.html
///
/// # Examples
///
/// ```
/// #![feature(layout_for_ptr)]
/// use std::mem;
///
/// assert_eq!(4, unsafe { mem::align_of_val_raw(&5i32) });
Expand All @@ -629,7 +640,8 @@ pub const fn align_of_val<T: ?Sized>(val: &T) -> usize {
/// [type-layout]: ../../reference/type-layout.html#r-layout.primitive
#[inline]
#[must_use]
#[unstable(feature = "layout_for_ptr", issue = "69835")]
#[stable(feature = "layout_for_ptr", since = "CURRENT_RUSTC_VERSION")]
#[rustc_const_stable(feature = "layout_for_ptr", since = "CURRENT_RUSTC_VERSION")]
pub const unsafe fn align_of_val_raw<T: ?Sized>(val: *const T) -> usize {
// SAFETY: the caller must provide a valid raw pointer
unsafe { intrinsics::align_of_val(val) }
Expand Down
1 change: 0 additions & 1 deletion library/coretests/tests/lib.rs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -82,7 +82,6 @@
#![feature(iter_partition_in_place)]
#![feature(iterator_try_collect)]
#![feature(iterator_try_reduce)]
#![feature(layout_for_ptr)]
#![feature(macro_metavar_expr_concat)]
#![feature(maybe_uninit_fill)]
#![feature(maybe_uninit_uninit_array_transpose)]
Expand Down
2 changes: 1 addition & 1 deletion src/tools/miri/tests/pass/intrinsics/intrinsics.rs
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,5 +1,5 @@
//@compile-flags: -Zmiri-permissive-provenance
#![feature(core_intrinsics, layout_for_ptr, ptr_metadata)]
#![feature(core_intrinsics, ptr_metadata)]
//! Tests for various intrinsics that do not fit anywhere else.
use std::intrinsics;
Expand Down
1 change: 0 additions & 1 deletion src/tools/miri/tests/pass/issues/issue-3200-packed-field-offset.rs
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,4 +1,3 @@
#![feature(layout_for_ptr)]
use std::mem;

#[repr(packed, C)]
Expand Down
1 change: 0 additions & 1 deletion src/tools/miri/tests/pass/issues/issue-3200-packed2-field-offset.rs
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,4 +1,3 @@
#![feature(layout_for_ptr)]
use std::mem;

#[repr(packed(4))]
Expand Down
2 changes: 1 addition & 1 deletion src/tools/miri/tests/pass/issues/issue-miri-2123.rs
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,4 +1,4 @@
#![feature(ptr_metadata, layout_for_ptr)]
#![feature(ptr_metadata)]

use std::{mem, ptr};

Expand Down
1 change: 0 additions & 1 deletion src/tools/miri/tests/pass/slices.rs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -3,7 +3,6 @@
//@[tree_implicit_writes]compile-flags: -Zmiri-tree-borrows -Zmiri-tree-borrows-implicit-writes
//@compile-flags: -Zmiri-strict-provenance
#![feature(slice_partition_dedup)]
#![feature(layout_for_ptr)]

use std::{ptr, slice};

Expand Down
2 changes: 0 additions & 2 deletions tests/ui/consts/const-size_of_val-align_of_val.rs
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,7 +1,5 @@
//@ run-pass

#![feature(layout_for_ptr)]

use std::{mem, ptr};

struct Foo(#[allow(dead_code)] u32);
Expand Down
1 change: 0 additions & 1 deletion tests/ui/packed/issue-118537-field-offset-ice.rs
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,5 +1,4 @@
//@ run-pass
#![feature(layout_for_ptr)]
use std::mem;

#[repr(packed(4))]
Expand Down
1 change: 0 additions & 1 deletion tests/ui/packed/issue-118537-field-offset.rs
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,5 +1,4 @@
//@ run-pass
#![feature(layout_for_ptr)]
use std::mem;

#[repr(packed, C)]
Expand Down
Loading