Docs & bors: Replace mentions of libs-api with libs

rust-bors.toml

@@ -17,7 +17,6 @@ labels_blocking_approval = [
     "S-waiting-on-MCP",
     "S-waiting-on-t-lang",
     "S-waiting-on-t-compiler",
-    "S-waiting-on-t-libs-api",
     "S-waiting-on-t-libs",
     "S-waiting-on-t-types",
     "S-waiting-on-t-opsem",

src/doc/rustc-dev-guide/src/stability.md

@@ -113,7 +113,7 @@ its corresponding `#![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
+1. Ask a **@T-libs** 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.
@@ -123,7 +123,7 @@ To stabilize a feature, follow these steps:
    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`.
+   - Add the appropriate labels: `@rustbot modify labels: +T-libs`.
    - Link to the tracking issue and say "Closes #XXXXX".
 
 You can see an example of stabilizing a feature with

src/doc/rustc-dev-guide/src/stabilization-guide.md

@@ -147,7 +147,7 @@ When opening the stabilization PR, CC the lang team and its advisors (`@rust-lan
 - `@rust-lang/types`, for type system interactions.
 - `@rust-lang/opsem`, for interactions with unsafe code.
 - `@rust-lang/compiler`, for implementation robustness.
-- `@rust-lang/libs-api`, for changes to the standard library API or its guarantees.
+- `@rust-lang/libs`, for changes to the standard library API or its guarantees.
 - `@rust-lang/lang-docs`, for questions about how this should be documented in the Reference.
 
 After the stabilization PR is opened with the stabilization report, wait a bit for any immediate comments.