stabilize size_of_val_raw, align_of_val_raw, Layout::for_value_raw
Stabilizes versions of `size_of_val_raw` and friends that can be invoked on raw pointers, which means they can be used even if one does not have a pointer to a "valid value". This was held up for a while because figuring out the exact safety requirements is tricky, but I think the ones we now have had for a while (plus the minor clarifications in this PR) are "good enough": we basically do case distinction on the unsized tail of the type, and spell out the appropriate requirement for each case. This avoids making blanket statements about future kinds of DST that we may introduce eventually.
These are the requirements I should we should stabilize:
```
    /// - If `T` is `Sized`, this function is always safe to call.
    /// - If the unsized tail of `T` is:
    ///     - 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.
    //        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).
    ///     - 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.
```
Going over the open questions from the [tracking issue](rust-lang#69835):
-  What should the exact safety requirements of these functions be? -> the currently documented requirement look good to me.
- How should this interact with extern types? -> what we document looks good here; we can still adjust this until extern types are stabilized.
- Are the functions sound to call on invalid data pointers? -> for the unsized tails that currently exist: yes; that's kind of the only reason to use them.
Cc @rust-lang/opsem @rust-lang/lang
(FCP should probably include both teams, unless lang is okay with fully delegating this to t-opsem)
I'll nominate the tracking issue for libs-api so we can get their approval as well for how the operation is exposed.
Fixes rust-lang#69835

stabilize size_of_val_raw, align_of_val_raw, Layout::for_value_raw
Stabilizes versions of `size_of_val_raw` and friends that can be invoked on raw pointers, which means they can be used even if one does not have a pointer to a "valid value". This was held up for a while because figuring out the exact safety requirements is tricky, but I think the ones we now have had for a while (plus the minor clarifications in this PR) are "good enough": we basically do case distinction on the unsized tail of the type, and spell out the appropriate requirement for each case. This avoids making blanket statements about future kinds of DST that we may introduce eventually.
These are the requirements I should we should stabilize:
```
    /// - If `T` is `Sized`, this function is always safe to call.
    /// - If the unsized tail of `T` is:
    ///     - 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.
    //        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).
    ///     - 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.
```
Going over the open questions from the [tracking issue](rust-lang#69835):
-  What should the exact safety requirements of these functions be? -> the currently documented requirement look good to me.
- How should this interact with extern types? -> what we document looks good here; we can still adjust this until extern types are stabilized.
- Are the functions sound to call on invalid data pointers? -> for the unsized tails that currently exist: yes; that's kind of the only reason to use them.
Cc @rust-lang/opsem @rust-lang/lang
(FCP should probably include both teams, unless lang is okay with fully delegating this to t-opsem)
I'll nominate the tracking issue for libs-api so we can get their approval as well for how the operation is exposed.
Fixes rust-lang#69835

…uwer
Rollup of 10 pull requests
Successful merges:
 - #157572 (stabilize size_of_val_raw, align_of_val_raw, Layout::for_value_raw)
 - #160012 (miri: ensure validity of references and pointers we dereference and cast)
 - #160294 (Update Enzyme to resolve one of the open bugs)
 - #159503 (allocations: document that they can be read-only)
 - #160250 (When issuing suggestions for missing trait items, label unstable items)
 - #160251 (Replace unsafe usage of `NonNull::new_unchecked` with `Box::into_non_null`)
 - #160311 (Remove final use of sealed traits from stdlib)
 - #160313 (Make the noundef-on-Cast size guard explicit)
 - #160323 (Box::leak: tell people to avoid unleaking)
 - #160328 (Move `check_track_caller` into the attribute parser)

…uwer
Rollup of 12 pull requests
Successful merges:
 - #157572 (stabilize size_of_val_raw, align_of_val_raw, Layout::for_value_raw)
 - #160012 (miri: ensure validity of references and pointers we dereference and cast)
 - #160294 (Update Enzyme to resolve one of the open bugs)
 - #159503 (allocations: document that they can be read-only)
 - #160179 (std: Update `wasip3` crate dependency)
 - #160250 (When issuing suggestions for missing trait items, label unstable items)
 - #160251 (Replace unsafe usage of `NonNull::new_unchecked` with `Box::into_non_null`)
 - #160311 (Remove final use of sealed traits from stdlib)
 - #160313 (Make the noundef-on-Cast size guard explicit)
 - #160323 (Box::leak: tell people to avoid unleaking)
 - #160328 (Move `check_track_caller` into the attribute parser)
 - #160333 (Remove itertools dependency from `rustc_ast_pretty`)

Rollup merge of #157572 - RalfJung:layout-of-raw, r=saethlin
stabilize size_of_val_raw, align_of_val_raw, Layout::for_value_raw
Stabilizes versions of `size_of_val_raw` and friends that can be invoked on raw pointers, which means they can be used even if one does not have a pointer to a "valid value". This was held up for a while because figuring out the exact safety requirements is tricky, but I think the ones we now have had for a while (plus the minor clarifications in this PR) are "good enough": we basically do case distinction on the unsized tail of the type, and spell out the appropriate requirement for each case. This avoids making blanket statements about future kinds of DST that we may introduce eventually.
These are the requirements I should we should stabilize:
```
    /// - If `T` is `Sized`, this function is always safe to call.
    /// - If the unsized tail of `T` is:
    ///     - 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.
    //        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).
    ///     - 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.
```
Going over the open questions from the [tracking issue](#69835):
-  What should the exact safety requirements of these functions be? -> the currently documented requirement look good to me.
- How should this interact with extern types? -> what we document looks good here; we can still adjust this until extern types are stabilized.
- Are the functions sound to call on invalid data pointers? -> for the unsized tails that currently exist: yes; that's kind of the only reason to use them.
Cc @rust-lang/opsem @rust-lang/lang
(FCP should probably include both teams, unless lang is okay with fully delegating this to t-opsem)
I'll nominate the tracking issue for libs-api so we can get their approval as well for how the operation is exposed.
Fixes #69835