Stability Attributes in Rust

# Stability attributes This section is about the stability attributes and schemes that allow stable APIs to use unstable APIs internally in the rustc standard library. **NOTE**: this section is for *library* features, not *language* features. For instructions on stabilizing a language feature see [Stabilizing Features](./stabilization_guide.md).  ## unstable The `#[unstable(feature = "foo", issue = "1234", reason = "lorem ipsum")]` attribute explicitly marks an item as unstable. Items that are marked as "unstable" cannot be used without a corresponding `#![feature]` attribute on the crate, even on a nightly compiler. This restriction only applies across crate boundaries, unstable items may be used within the crate that defines them. The `issue` field specifies the associated GitHub [issue number]. This field is required and all unstable features should have an associated tracking issue. In rare cases where there is no sensible value `issue = "none"` is used. The `unstable` attribute infects all sub-items, where the attribute doesn't have to be reapplied. So if you apply this to a module, all items in the module will be unstable. You can make specific sub-items stable by using the `#[stable]` attribute on them. The stability scheme works similarly to how `pub` works. You can have public functions of nonpublic modules and you can have stable functions in unstable modules or vice versa. Previously, due to a [rustc bug], stable items inside unstable modules were available to stable code in that location. As of  September 2024, items with [accidentally stabilized paths] are marked with the `#[rustc_allowed_through_unstable_modules]` attribute to prevent code dependent on those paths from breaking. Do *not* add this attribute to any more items unless that is needed to avoid breaking changes. The `unstable` attribute may also have the `soft` value, which makes it a future-incompatible deny-by-default lint instead of a hard error. This is used by the `bench` attribute which was accidentally accepted in the past. This prevents breaking dependencies by leveraging Cargo's lint capping. ## stable The `#[stable(feature = "foo", since = "1.420.69")]` attribute explicitly marks an item as stabilized. Note that stable functions may use unstable things in their body. ## rustc_const_unstable The `#[rustc_const_unstable(feature = "foo", issue = "1234", reason = "lorem ipsum")]` has the same interface as the `unstable` attribute. It is used to mark `const fn` as having their constness be unstable. This is only needed in rare cases: - If a `const fn` makes use of unstable language features or intrinsics. (The compiler will tell you to add the attribute if you run into this.) - If a `const fn` is `#[stable]` but not yet intended to be const-stable. - To change the feature gate that is required to call a const-unstable intrinsic. Const-stability differs from regular stability in that it is *recursive*: a `#[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

This section describes the attributes used to manage stability in Rust's standard library, focusing on allowing stable APIs to use unstable APIs internally. It details the `#[unstable]`, `#[stable]`, `#[rustc_const_unstable]`, `#[rustc_const_stable]`, and `#[rustc_const_stable_indirect]` attributes, explaining their usage, parameters (feature name, issue number, reason, since version), and how they affect the visibility and usage of functions and modules, especially concerning const functions and feature gating.