Stabilize mem::conjure_zst

[theemathas]

Tracking issue: #95383

---

Stabilized API:

pub const unsafe fn conjure_zst<T>() -> T;

The notable thing about this implementation is that if this function is called at run time (as opposed to in consteval), then the function will panic at run time (as opposed to at compile time) if T is not a ZST.

If the function panics in consteval, the panic message is a fixed literal string. If the function panics at run time, the panic message includes the type_name of T. Note that type_name is currently unstable in const.

---

Implementation history:

• Add mem::conjure_zst for creating ZSTs out of nothing #95385 (attempted to add the API without an ACP, and then the PR was closed)
• Add an unsafe fn for creating a ZST libs-team#292 (The ACP. It has a lot of additional context and discussion, including the explanation of why this is needed)
• add mem::conjure_zst #146479 (the actual implementation)
• Fix mem::conjure_zst panic message to use any::type_name instead #153073 (changes the panic message)
• prefer T::IS_ZST over manual check #155840 (internal implementation change)

[rustbot]

⚠️ #[rustc_allow_const_fn_unstable] needs careful audit to avoid accidentally exposing unstable
implementation details on stable.

cc @rust-lang/wg-const-eval

[rustbot]

r? @clarfonthey

rustbot has assigned @clarfonthey.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

• Owners of files modified in this PR: libs
• libs expanded to 12 candidates
• Random selection from JohnTitor, Mark-Simulacrum, clarfonthey, nia-e

[RalfJung]

This might be the first time we use the term "safety invariant" in the docs? Elsewhere we describe the concept rather than naming it, e.g. https://doc.rust-lang.org/nightly/std/mem/union.MaybeUninit.html#method.assume_init :

On top of that, remember that most types have additional invariants beyond merely being considered initialized at the type level. For example, a 1-initialized Vec is considered initialized (under the current implementation; this does not constitute a stable guarantee) because the only requirement the compiler knows about it is that the data pointer must be non-null. Creating such a Vec does not cause immediate undefined behavior, but will cause undefined behavior with most safe operations (including dropping it).

View changes since the review

[nia-e]

@rfcbot fcp merge libs

[rust-rfcbot]

@nia-e has proposed to merge this. The next step is review by the rest of the tagged team members:

• @Amanieu
• @BurntSushi
• @cuviper
• @dtolnay
• @joshtriplett
• @the8472
• @thomcc

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.