Partially stabilize (const_)slice_ptr_len feature by stabilizing NonNull::len

[Pointerbender]

This PR partially stabilizes features const_slice_ptr_len and slice_ptr_len by only stabilizing NonNull::len. This partial stabilization is tracked under features slice_ptr_len_nonnull and const_slice_ptr_len_nonnull, for which this PR can serve as the tracking issue.

To summarize the discussion from #71146 leading up to this partial stabilization request:

It's currently a bit footgunny to obtain the length of a raw slice pointer, stabilization of NonNull:len will help with removing these footguns. Some example footguns are:

/// # Safety
/// The caller must ensure that `ptr`:
/// 1. does not point to memory that was previously allocated but is now deallocated;
/// 2. is within the bounds of a single allocated object;
/// 3. does not to point to a slice for which the length exceeds `isize::MAX` bytes;
/// 4. points to a properly aligned address;
/// 5. does not point to uninitialized memory;
/// 6. does not point to a mutably borrowed memory location.
pub unsafe fn ptr_len<T>(ptr: core::ptr::NonNull<[T]>) -> usize {
   (&*ptr.as_ptr()).len()
}

A slightly less complicated version (but still more complicated than it needs to be):

/// # Safety
/// The caller must ensure that the start of `ptr`:
/// 1. does not point to memory that was previously allocated but is now deallocated;
/// 2. must be within the bounds of a single allocated object.
pub unsafe fn ptr_len<T>(ptr: NonNull<[T]>) -> usize {
   (&*(ptr.as_ptr() as *const [()])).len()
}

This PR does not stabilize <*const [T]>::len and <*mut [T]>::len because the tracking issue #71146 list a potential blocker for these methods, but this blocker does not apply to NonNull::len.

We should probably also ping the Constant Evaluation WG since this PR includes a #[rustc_allow_const_fn_unstable(const_slice_ptr_len)]. My instinct here is that this will probably be okay because the pointer is not actually dereferenced and len() does not touch the address component of the pointer, but would be best to double check :)

One potential down-side was raised that stabilizing NonNull::len could lead to encouragement of coding patterns like:

pub fn ptr_len<T>(ptr: *mut [T]) -> usize {
   NonNull::new(ptr).unwrap().len()
}

which unnecessarily assert non-nullness. However, these are much less of a footgun than the above examples and this should be resolved when slice_ptr_len fully stabilizes eventually.

[rust-highfive]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @yaahc (or someone else) soon.

Please see the contribution instructions for more information.

[jhpratt]

Diff LGTM. Feature is properly split and attributes are correct.

cc @oli-obk for the usage of #[rustc_allow_const_fn_unstable] — I believe this usage should be fine.

[m-ou-se]

@rfcbot merge

[rfcbot]

Team member @m-ou-se has proposed to merge this. The next step is review by the rest of the tagged team members:

• @Amanieu
• @BurntSushi
• @dtolnay
• @joshtriplett
• @m-ou-se
• @yaahc

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[bstrie]

+1, extremely in favor of this. Thanks for doing the work here @Pointerbender !

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[rfcbot]

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

This will be merged soon.

[yaahc]

Thank you again @Pointerbender!

@bors r+

[bors]

📌 Commit 021a7e4 has been approved by yaahc