Const Stability Attributes and Feature Stabilization Process

`#[rustc_const_unstable(...)]` function cannot even be indirectly called from stable code. This is to avoid accidentally leaking unstable compiler implementation artifacts to stable code or locking us into the accidental quirks of an incomplete implementation. See the rustc_const_stable_indirect and rustc_allow_const_fn_unstable attributes below for how to fine-tune this check. ## rustc_const_stable The `#[rustc_const_stable(feature = "foo", since = "1.420.69")]` attribute explicitly marks a `const fn` as having its constness be `stable`. ## rustc_const_stable_indirect The `#[rustc_const_stable_indirect]` attribute can be added to a `#[rustc_const_unstable(...)]` function to make it callable from `#[rustc_const_stable(...)]` functions. This indicates that the function is ready for stable in terms of its implementation (i.e., it doesn't use any unstable compiler features); the only reason it is not const-stable yet are API concerns. This should also be added to lang items for which const-calls are synthesized in the compiler, to ensure those calls do not bypass recursive const stability rules. ## rustc_intrinsic_const_stable_indirect On an intrinsic, this attribute marks the intrinsic as "ready to be used by public stable functions". If the intrinsic has a `rustc_const_unstable` attribute, it should be removed. **Adding this attribute to an intrinsic requires t-lang and wg-const-eval approval!** ## rustc_default_body_unstable The `#[rustc_default_body_unstable(feature = "foo", issue = "1234", reason = "lorem ipsum")]` attribute has the same interface as the `unstable` attribute. It is used to mark the default implementation for an item within a trait as unstable. A trait with a default-body-unstable item can be implemented stably by providing an explicit body for any such item, or the default body can be used by enabling its corresponding `#![feature]`. ## Stabilizing a library feature To stabilize a feature, follow these steps: 1. Ask a **@T-libs-api** member to start an FCP on the tracking issue and wait for the FCP to complete (with `disposition-merge`). 2. Change `#[unstable(...)]` to `#[stable(since = "CURRENT_RUSTC_VERSION")]`. 3. Remove `#![feature(...)]` from any test or doc-test for this API. If the feature is used in the compiler or tools, remove it from there as well. 4. If this is a `const fn`, add `#[rustc_const_stable(since = "CURRENT_RUSTC_VERSION")]`. Alternatively, if this is not supposed to be const-stabilized yet, add `#[rustc_const_unstable(...)]` for some new feature gate (with a new tracking issue). 5. Open a PR against `rust-lang/rust`. - Add the appropriate labels: `@rustbot modify labels: +T-libs-api`. - Link to the tracking issue and say "Closes #XXXXX". You can see an example of stabilizing a feature with [tracking issue #81656 with FCP](https://github.com/rust-lang/rust/issues/81656) and the associated [implementation PR #84642](https://github.com/rust-lang/rust/pull/84642).

This section details const stability attributes (`rustc_const_stable`, `rustc_const_stable_indirect`, `rustc_intrinsic_const_stable_indirect`) and the `rustc_default_body_unstable` attribute, explaining their roles in controlling const function stability and default trait implementations. It also outlines the step-by-step process for stabilizing a library feature in Rust, including requesting an FCP, updating attributes, removing feature gates, and submitting a pull request.