Add ptr::{str_from_raw_parts, str_from_raw_parts_mut} functions

[WaffleLapkin]

TL;DR: this PR adds the following API:

// core::ptr
pub const fn str_from_raw_parts(data: *const u8, len: usize) -> *const str;
pub const fn str_from_raw_parts_mut(data: *mut u8, len: usize) -> *mut str;

impl NonNull<str> {
    pub const fn str_from_raw_parts(data: NonNull<u8>, len: usize) -> Self;
}

The functions are under feature gate str_from_raw_parts and are similar to
slice_from_raw_parts, slice_from_raw_parts_mut and NonNull::slice_from_raw_parts.

---

These methods were originally proposed as a part of #85816 and there were some concerns about the specific design we should use for str pointer construction.

Some alternative designs:

• "Blessed cast"

  // core::ptr
  pub const fn str_from_raw_utf8(raw: *const [u8]) -> *const str;
  pub const fn str_from_raw_utf8_mut(raw: *mut [u8]) -> *mut str;
  // Also NonNull?

  Pros: similar to already existing &str construction (str::from_utf8)
  Cons: forces to use 2 functions (str_from_raw_utf8(slice_from_raw_parts(ptr, len))) to convert ptr, len into *const str
• Add str::from_raw_parts too (addition to the current design of this PR)

  // core::str
  pub const unsafe fn from_raw_parts<'a>(ptr: *const u8, len: usize) -> &'a str;
  pub const unsafe fn from_raw_parts_mut<'a>(ptr: *mut u8, len: usize) -> &'a mut str;

  Pros: similar to slices
  Cons: adds a function to str which can be replaced with slice::from_raw_parts and str::from_utf8_unchecked (in this case having two functions is probably better, as it splits safety conditions into smaller parts)
• Do nothing, use ptr::from_raw_parts
  Pros: doesn't add anything new, reuses existing API
  Cons: less clear/longer stabilization path

[rust-highfive]

r? @m-ou-se

(rust-highfive has picked a reviewer for you, use r? to override)

[m-ou-se]

r? @dtolnay

[dtolnay]

I would prefer not to add these. In the long term, ptr::from_raw_parts should be fine for this use case. In the short term, it sounded like the only immediate motivation for adding these APIs was:

#85816 (comment)
it seemed weird to have methods on *const str without a convenient way to create such pointers

This isn't compelling to me because people are successfully and reasonably conveniently working with *const str in real code today; they aren't the ones asking for this. A few examples:

as cast from *const [u8]:

rust/library/alloc/src/rc.rs

Lines 1818 to 1819 in 23f6923

	let rc = Rc::<[u8]>::from(v.as_bytes());
	unsafe { Rc::from_raw(Rc::into_raw(rc) as *const str) }

as cast from &str:

rust/compiler/rustc_span/src/symbol.rs

Lines 1767 to 1772 in 23f6923

	let string: &str =
	unsafe { str::from_utf8_unchecked(inner.arena.alloc_slice(string.as_bytes())) };
	// SAFETY: we can extend the arena allocation to `'static` because we
	// only access these while the arena is still alive.
	let string: &'static str = unsafe { &*(string as *const str) };

[WaffleLapkin]

@dtolnay that makes sense. I didn't know the *const [u8] can be cast to *const str, I thought that as only worked for pointers to sized types...

Considering how easy it is to construct *const str and ptr::from_raw_parts, this proposal indeed doesn't seem to be useful enough. Closing as such.