Stable Language Evolution

Tracking Issues

Every unstable language feature or standard library API in Rust is linked to a dedicated Tracking Issue in the rust-lang/rust GitHub repository. When you attempt to call an unstable API on a stable compiler, rustc prints the exact tracking issue number (see issue #NNNNN) so you can immediately check its design status, remaining blockers, and stabilization timeline.

Compiler Diagnostic Pointing to a Tracking Issue:

  error[E0658]: use of unstable library feature `try_blocks`
   --> src/main.rs:4:15
    |
  4 |     let res = try { ... };
    |               ^^^
    |
    = note: see issue #31436 <https://github.com/rust-lang/rust/issues/31436> for more information
    = help: add `#![feature(try_blocks)]` to the crate attributes to enable

Anatomy of a rust-lang/rust Tracking Issue

A tracking issue acts as the central living document for an unstable feature from initial implementation until stabilization:

Tracking Issue Section What It Contains
Feature Gate Name Exact #![feature(<name>)] identifier (e.g., #![feature(gen_blocks)]).
Originating RFC / ACP Link to the approved RFC document or Libs-API Change Proposal (ACP).
Public API Surface Exact signatures of all types, traits, and functions guarded by the feature gate.
Steps / Checklist Checkbox list: [x] Implement feature, [ ] Resolve unresolved questions, [ ] Add documentation, [ ] Stabilization PR.
Unresolved Questions Specific corner cases (e.g., interaction with drop order, type inference, or lifetimes) that must be answered before stabilization.
FCP (Final Comment Period) Bot Status @rfcbot fcp merge checklist showing which team members (T-lang, T-libs-api, T-compiler) have reviewed and checked off stabilization!

Reading FCP (@rfcbot) Signals on a Tracking Issue

When a feature's unresolved questions are all answered and a Stabilization Report is posted on the tracking issue (or on a stabilization pull request), a team member invokes @rfcbot fcp merge:

  1. disposition-merge (Proposed FCP): Team members are actively reviewing the stabilization checklist.
  2. final-comment-period (Active 10-Day FCP): All required team checkboxes are checked; a 10-day public window begins for the community to raise any last-minute soundness or design concerns.
  3. finished-final-comment-period: The 10-day FCP succeeded, and the stabilization PR is merged into master (scheduled to ship in the stable release 6 to 12 weeks later!).
#[derive(Debug, Clone, Copy, PartialEq, Eq)]
pub enum FeatureStage {
    NightlyExperimental { issue: u32, unresolved_items: usize },
    ProposedFcp { issue: u32, remaining_signoffs: usize },
    FinalCommentPeriod { issue: u32, days_left: u8 },
    Stabilized { since_version: &'static str },
}

impl FeatureStage {
    pub fn is_usable_on_stable(&self) -> bool {
        matches!(self, FeatureStage::Stabilized { .. })
    }
}

fn main() {
    let lazy_lock = FeatureStage::Stabilized {
        since_version: "1.80.0",
    };
    let try_blocks = FeatureStage::NightlyExperimental {
        issue: 31436,
        unresolved_items: 2,
    };

    assert!(lazy_lock.is_usable_on_stable());
    assert!(!try_blocks.is_usable_on_stable());

    println!("LazyLock stable: {}, try_blocks stable: {}", lazy_lock.is_usable_on_stable(), try_blocks.is_usable_on_stable());
}

LazyLock stable: true, try_blocks stable: false