Stabilizing Language Features in Rust

# Request for stabilization **NOTE**: this page is about stabilizing *language* features. For stabilizing *library* features, see [Stabilizing a library feature]. Once an unstable feature has been well-tested with no outstanding concern, anyone may push for its stabilization. It involves the following steps:  ## Documentation PRs <a id="updating-documentation"></a> If any documentation for this feature exists, it should be in the [`Unstable Book`], located at [`src/doc/unstable-book`]. If it exists, the page for the feature gate should be removed. If there was documentation there, integrating it into the existing documentation is needed. If there wasn't documentation there, it needs to be added. Places that may need updated documentation: If you're not sure, please open an issue on this repository and it can be discussed. - standard library documentation: As needed. Language features often don't need this, but if it's a feature that changes how good examples are written, such as when `?` was added to the language, updating examples is important. Prepare PRs to update documentation involving this new feature for repositories mentioned above. Maintainers of these repositories will keep these PRs open until the whole stabilization process has completed. Meanwhile, we can proceed to the next step. ## Write a stabilization report Find the tracking issue of the feature, and create a short stabilization report. Essentially this would be a brief summary of the feature plus some links to test cases showing it works as expected, along with a list of edge cases that came up and were considered. This is a minimal "due diligence" that we do before stabilizing. The report should contain: - A summary, showing examples (e.g. code snippets) what is enabled by this feature. - Links to test cases in our test suite regarding this feature and describe the feature's behavior on encountering edge cases. - Links to the documentations (the PRs we have made in the previous steps). - Any other relevant information. - The resolutions of any unresolved questions if the stabilization is for an RFC. Examples of stabilization reports can be found in [rust-lang/rust#44494][report1] and [rust-lang/rust#28237][report2] (these links will bring you directly to the comment containing the stabilization report). ## FCP If any member of the team responsible for tracking this feature agrees with stabilizing this feature, they will start the FCP (final-comment-period) process by commenting ```text @rfcbot fcp merge ``` The rest of the team members will review the proposal. If the final decision is to stabilize, we proceed to do the actual code modification. ## Stabilization PR *This is for stabilizing language features. If you are stabilizing a library feature, see [the stabilization chapter of the std dev guide][std-guide-stabilization] instead.* Once we have decided to stabilize a feature, we need to have a PR that actually makes that stabilization happen. These kinds of PRs are a great way to get involved in Rust, as they take you on a little tour through the source code. Here is a general guide to how to stabilize a feature -- every feature is different, of course, so some features may

This section outlines the process for stabilizing language features in Rust. It includes creating documentation PRs, writing a stabilization report, initiating the FCP (Final Comment Period) process, and submitting a stabilization PR. The guide covers updating documentation, providing examples and test cases, addressing edge cases, and linking relevant information to ensure a smooth transition of well-tested features from unstable to stable.