Add a separate Stabilization PR section for Library Features

Because sending people doing library stabilization to `feature_gate.rs` will just result in confusion.

Author: scottmcm

src/stabilization_guide.md

@@ -82,7 +82,7 @@ start the FCP (final-comment-period) process by commenting
 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
+## Stabilization PR for Language Features
 
 Once we have decided to stabilize a feature, we need to have
 a PR that actually makes that stabilization happen. These kinds
@@ -183,6 +183,73 @@ if self.tcx.sess.features.borrow().pub_restricted && something { /* XXX */ }
 if something { /* XXX */ }
 ```
 
+## Stabilization PR for Library Features
+
+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're typically
+small -- just updating attributes.
+
+Here is a general guide to how to stabilize a feature --
+every feature is different, of course, so some features may
+require steps beyond what this guide talks about.
+
+### Update the stability attributes on the items
+
+Library items are marked unstable via the `#[unstable]` attribute, like this:
+
+```rust,ignore
+#[unstable(feature = "total_cmp", issue = "72599")]
+pub fn total_cmp(&self, other: &Self) -> crate::cmp::Ordering { ... }
+```
+
+You'll need to change that to a `#[stable]` attribute with a version:
+
+```rust,ignore
+#[stable(feature = "total_cmp", since = "1.61.0")]
+```
+
+Note that, the version number is updated to be the version number
+of the stable release where this feature will appear. This can be
+found by consulting [the forge](https://forge.rust-lang.org/#current-release-versions).
+Specifically, you'll want to use the version labelled "Nightly".
+That's two versions higher than the current stable release,
+as what's currently in beta will be the next stable release,
+and any change you're making now will be in the one after that.
+
+### Remove feature gates from doctests
+
+All the doctests on the items being stabilized will be enabling the unstable feature,
+so now that it's stable those attributes are no longer needed and should be removed.
+
+`````diff
+ /// # Examples
+ ///
+ /// ```
+-/// #![feature(total_cmp)]
+-///
+ /// assert_eq!(0.0_f32.total_cmp(&-0.0), std::cmp::Ordering::Greater);
+ /// ```
+`````
+
+The most obvious place to find these is on the item itself,
+but it's worth searching the whole library.  Often you'll find
+other unstable methods that were also using it in their tests.
+
+### Remove feature gates from the compiler
+
+The compiler builds with nightly features allowed, so you may find uses of
+the feature there as well.  These also need to be removed.
+
+```diff
+ #![feature(once_cell)]
+ #![feature(never_type)]
+-#![feature(total_cmp)]
+ #![feature(trusted_step)]
+ #![feature(try_blocks)]
+```
+
+
 [rust-lang/rust#32409]: https://github.com/rust-lang/rust/issues/32409
 [`compiler/rustc_feature`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_feature/index.html
 [The Reference]: https://github.com/rust-lang/reference