Rollup merge of #152477 - tshepang:rdg-sync, r=tshepang

rustc-dev-guide subtree update

Subtree update of `rustc-dev-guide` to 1a02979fae.

Created using https://github.com/rust-lang/josh-sync.

r? @ghost

src/doc/rustc-dev-guide/ci/date-check/src/main.rs

@@ -163,6 +163,9 @@ fn main() {
             }
         }
         println!();
+
+        println!("@rustbot label +C-date-reference-triage +E-easy +E-help-wanted");
+        println!();
     }
 }
 

src/doc/rustc-dev-guide/examples/rustc-interface-example.rs

@@ -28,12 +28,11 @@ fn main() {
     println!("{HELLO}");
 }
 "#
-            .into(),
+                .into(),
         },
-        output_dir: None,  // Option<PathBuf>
-        output_file: None, // Option<PathBuf>
-        file_loader: None, // Option<Box<dyn FileLoader + Send + Sync>>
-        locale_resources: rustc_driver::DEFAULT_LOCALE_RESOURCES.to_owned(),
+        output_dir: None,                // Option<PathBuf>
+        output_file: None,               // Option<PathBuf>
+        file_loader: None,               // Option<Box<dyn FileLoader + Send + Sync>>
         lint_caps: FxHashMap::default(), // FxHashMap<lint::LintId, lint::Level>
         // This is a callback from the driver that is called when [`ParseSess`] is created.
         psess_created: None, //Option<Box<dyn FnOnce(&mut ParseSess) + Send>>
@@ -73,4 +72,4 @@ fn main() {
             }
         });
     });
-}
+}

src/doc/rustc-dev-guide/examples/rustc-interface-getting-diagnostics.rs

@@ -59,14 +59,13 @@ fn main() {
     let x: &str = 1;
 }
 "
-            .into(),
+                .into(),
         },
         crate_cfg: Vec::new(),
         crate_check_cfg: Vec::new(),
         output_dir: None,
         output_file: None,
         file_loader: None,
-        locale_resources: rustc_driver::DEFAULT_LOCALE_RESOURCES.to_owned(),
         lint_caps: rustc_hash::FxHashMap::default(),
         psess_created: Some(Box::new(|parse_sess| {
             parse_sess.dcx().set_emitter(Box::new(DebugEmitter {
@@ -98,4 +97,4 @@ fn main() {
     buffer.lock().unwrap().iter().for_each(|diagnostic| {
         println!("{diagnostic:#?}");
     });
-}
+}

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

@@ -124,7 +124,7 @@
     - [`#[test]` implementation](./test-implementation.md)
     - [Panic implementation](./panic-implementation.md)
     - [AST validation](./ast-validation.md)
-    - [Feature gate checking](./feature-gate-ck.md)
+    - [Feature gate checking](./feature-gate-check.md)
     - [Lang Items](./lang-items.md)
 - [The HIR (High-level IR)](./hir.md)
     - [Lowering AST to HIR](./hir/lowering.md)

src/doc/rustc-dev-guide/src/about-this-guide.md

@@ -10,7 +10,7 @@ There are several parts to this guide:
    about building, debugging, profiling, etc.
 1. [Contributing to Rust][p2]:
    Contains information that should be useful no matter how you are contributing,
-   about procedures for contribution, using git and Github, stabilizing features, etc.
+   about procedures for contribution, using git and GitHub, stabilizing features, etc.
 1. [Bootstrapping][p3]:
    Describes how the Rust compiler builds itself using previous versions, including
    an introduction to the bootstrap process and debugging methods.

src/doc/rustc-dev-guide/src/building/bootstrapping/what-bootstrapping-does.md

@@ -243,7 +243,7 @@ This is also where `--keep-stage 1 library/std` comes into play. Since most
 changes to the compiler don't actually change the ABI, once you've produced a
 `std` in `stage1`, you can probably just reuse it with a different compiler. If
 the ABI hasn't changed, you're good to go, no need to spend time recompiling
-that `std`. The flag `--keep-stage` simply instructs the build script to assumes
+that `std`. The flag `--keep-stage` simply instructs the build script to assume
 the previous compile is fine and copies those artifacts into the appropriate
 place, skipping the `cargo` invocation.
 
@@ -342,7 +342,7 @@ This flag has the following effects:
 
 Code which does not use `-Z force-unstable-if-unmarked` should include the
 `#![feature(rustc_private)]` crate attribute to access these forced-unstable
-crates. This is needed for things which link `rustc` its self, such as `MIRI` or
+crates. This is needed for things which link `rustc` itself, such as `Miri` or
 `clippy`.
 
 You can find more discussion about sysroots in:

src/doc/rustc-dev-guide/src/building/suggested.md

@@ -56,7 +56,7 @@ You can also include extensions within extensions recursively.
 **Note:** In the `include` field, the overriding logic follows a right-to-left order.
 For example,
 in `include = ["a.toml", "b.toml"]`, extension `b.toml` overrides `a.toml`.
-Also, parent extensions always overrides the inner ones.
+Also, parent extensions always override the inner ones.
 
 ## Configuring `rust-analyzer` for `rustc`
 
@@ -426,7 +426,7 @@ You can then use that rust2 folder as a separate workspace for modifying and bui
 
 Several nix configurations are defined in `src/tools/nix-dev-shell`.
 
-If you're using direnv, you can create a symbol link to `src/tools/nix-dev-shell/envrc-flake` or `src/tools/nix-dev-shell/envrc-shell`
+If you're using direnv, you can create a symbolic link to `src/tools/nix-dev-shell/envrc-flake` or `src/tools/nix-dev-shell/envrc-shell`
 
 ```bash
 ln -s ./src/tools/nix-dev-shell/envrc-flake ./.envrc # Use flake
@@ -436,6 +436,12 @@ or
 ln -s ./src/tools/nix-dev-shell/envrc-shell ./.envrc # Use nix-shell
 ```
 
+If you're using the flake, make sure to also update it with the following command:
+
+```
+nix flake update --flake ./src/tools/nix-dev-shell
+```
+
 ### Note
 
 Note that when using nix on a not-NixOS distribution, it may be necessary to set

src/doc/rustc-dev-guide/src/const-generics.md

@@ -61,7 +61,7 @@ In some sense the desugarings from the previous examples are to:
 struct Foo<const N: usize>;
 type Alias = [u8; 1 + 1];
 
-// sort-of desugars to psuedo-rust:
+// sort-of desugars to pseudo-rust:
 struct Foo<const N: usize>;
 
 const ANON = 1 + 1;
@@ -178,7 +178,7 @@ To check this we have [`ClauseKind::ConstArgHasType(ty::Const, Ty)`][const_arg_h
 ```rust
 fn foo<const N: usize>() {}
 
-// desugars to in psuedo-rust
+// desugars to in pseudo-rust
 
 fn foo<const N>()
 where

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

@@ -324,7 +324,7 @@ When you resolve them, you should use `@rustbot` to mark it as `S-waiting-on-rev
 GitHub allows [closing issues using keywords][closing-keywords].
 This feature should be used to keep the issue tracker tidy.
 However, it is generally preferred
-to put the "closes #123" text in the PR description rather than the issue commit;
+to put the "closes #123" text in the PR description rather than the commit message;
 particularly during rebasing, citing the issue number in the commit can "spam"
 the issue in question.
 

src/doc/rustc-dev-guide/src/crates-io.md

@@ -1,23 +1,13 @@
 # crates.io dependencies
 
 The Rust compiler supports building with some dependencies from `crates.io`.
-Examples are `log` and `env_logger`.
 
-In general,
-you should avoid adding dependencies to the compiler for several reasons:
-
-- The dependency may not be of high quality or well-maintained.
-- The dependency may not be using a compatible license.
-- The dependency may have transitive dependencies that have one of the above
-  problems.
-
-<!-- date-check: Aug 2025 -->
-Note that there is no official policy for vetting new dependencies to the compiler.
-Decisions are made on a case-by-case basis, during code review.
+Rust Forge has [official policy for vetting new dependencies].
 
 ## Permitted dependencies
 
-The `tidy` tool has [a list of crates that are allowed]. To add a
-dependency that is not already in the compiler, you will need to add it to the list.
+The `tidy` tool has [a list of crates that are allowed].
+To add a dependency that is not already in the compiler, you will need to add it to the list.
 
 [a list of crates that are allowed]: https://github.com/rust-lang/rust/blob/9d1b2106e23b1abd32fce1f17267604a5102f57a/src/tools/tidy/src/deps.rs#L73
+[official policy for vetting new dependencies]: https://forge.rust-lang.org/compiler/third-party-out-of-tree#third-party-crates

src/doc/rustc-dev-guide/src/debugging-support-in-rustc.md

@@ -216,7 +216,7 @@ trait for a type would be one of these interfaces (`DW_tag_interface` type). Als
 which it is implemented would describe all the interfaces this type implements. This requires a
 DWARF extension.
 
-Issue on Github: [https://github.com/rust-lang/rust/issues/33014]
+Issue on GitHub: [https://github.com/rust-lang/rust/issues/33014]
 
 ## Typical process for a Debug Info change (LLVM)
 

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

@@ -228,7 +228,7 @@ Guidelines for different diagnostic levels:
   The error or warning portion should *not* suggest how to fix the problem,
   only the "help" sub-diagnostic should.
 
-- `note`: emitted to given more context and identify additional circumstances
+- `note`: emitted to give more context and identify additional circumstances
   and parts of the code that caused the warning or error. For example, the
   borrow checker will note any previous conflicting borrows.
 
@@ -788,7 +788,7 @@ add_lint_group!(sess,
 ```
 
 This defines the `nonstandard_style` group which turns on the listed lints. A
-user can turn on these lints with a `!#[warn(nonstandard_style)]` attribute in
+user can turn on these lints with a `#![warn(nonstandard_style)]` attribute in
 the source code, or by passing `-W nonstandard-style` on the command line.
 
 Some lint groups are created automatically in `LintStore::register_lints`. For instance,
@@ -944,7 +944,7 @@ You can filter on the following boolean flags:
  - `crate_local`: whether the code causing the trait bound to not be
    fulfilled is part of the user's crate. This is used to avoid suggesting
    code changes that would require modifying a dependency.
- - `direct`: whether this is an user-specified rather than derived obligation.
+ - `direct`: whether this is a user-specified rather than derived obligation.
  - `from_desugaring`: whether we are in some kind of desugaring, like `?`
    or a `try` block for example. This flag can also be matched on, see below.
 

src/doc/rustc-dev-guide/src/diagnostics/diagnostic-structs.md

@@ -12,7 +12,7 @@ customizing the rendering logic, or selecting messages at runtime, you will need
 the corresponding trait (`Diagnostic`, `LintDiagnostic`, or `Subdiagnostic`).
 This approach provides greater flexibility and is recommended for diagnostics that go beyond simple, static structures.
 
-Diagnostic can be translated into different languages and each has a slug that uniquely identifies the diagnostic.
+Diagnostic can be translated into different languages.
 
 ## `#[derive(Diagnostic)]` and `#[derive(LintDiagnostic)]`
 
@@ -21,13 +21,13 @@ shown below:
 
 ```rust,ignore
 #[derive(Diagnostic)]
-#[diag(hir_analysis_field_already_declared, code = E0124)]
+#[diag("field `{$field_name}` is already declared", code = E0124)]
 pub struct FieldAlreadyDeclared {
     pub field_name: Ident,
     #[primary_span]
-    #[label]
+    #[label("field already declared")]
     pub span: Span,
-    #[label(previous_decl_label)]
+    #[label("`{$field_name}` first declared here")]
     pub prev_span: Span,
 }
 ```
@@ -42,25 +42,10 @@ the `code` sub-attribute. Specifying a `code` isn't mandatory, but if you are
 porting a diagnostic that uses `Diag` to use `Diagnostic`
 then you should keep the code if there was one.
 
-`#[diag(..)]` must provide a slug as the first positional argument (a path to an
-item in `rustc_errors::fluent::*`). A slug uniquely identifies the diagnostic
-and is also how the compiler knows what error message to emit (in the default
-locale of the compiler, or in the locale requested by the user). See
+`#[diag(..)]` must provide a message as the first positional argument. 
+The message is written in English, but might be translated to the locale requested by the user. See
 [translation documentation](./translation.md) to learn more about how
-translatable error messages are written and how slug items are generated.
-
-In our example, the Fluent message for the "field already declared" diagnostic
-looks like this:
-
-```fluent
-hir_analysis_field_already_declared =
-    field `{$field_name}` is already declared
-    .label = field already declared
-    .previous_decl_label = `{$field_name}` first declared here
-```
-
-`hir_analysis_field_already_declared` is the slug from our example and is followed
-by the diagnostic message.
+translatable error messages are written and how they are generated.
 
 Every field of the `Diagnostic` which does not have an annotation is
 available in Fluent messages as a variable, like `field_name` in the example
@@ -76,13 +61,7 @@ specified on a `Diagnostic`.
 
 `#[label]`, `#[help]`, `#[warning]` and `#[note]` can all be applied to fields which have the
 type `Span`. Applying any of these attributes will create the corresponding
-subdiagnostic with that `Span`. These attributes will look for their
-diagnostic message in a Fluent attribute attached to the primary Fluent
-message. In our example, `#[label]` will look for
-`hir_analysis_field_already_declared.label` (which has the message "field already
-declared"). If there is more than one subdiagnostic of the same type, then
-these attributes can also take a value that is the attribute name to look for
-(e.g. `previous_decl_label` in our example).
+subdiagnostic with that `Span`. These attributes take a diagnostic message as an argument.
 
 Other types have special behavior when used in a `Diagnostic` derive:
 
@@ -99,17 +78,17 @@ represent optional `#[note]`/`#[help]`/`#[warning]` subdiagnostics.
 
 Suggestions can be emitted using one of four field attributes:
 
-- `#[suggestion(slug, code = "...", applicability = "...")]`
-- `#[suggestion_hidden(slug, code = "...", applicability = "...")]`
-- `#[suggestion_short(slug, code = "...", applicability = "...")]`
-- `#[suggestion_verbose(slug, code = "...", applicability = "...")]`
+- `#[suggestion("message", code = "...", applicability = "...")]`
+- `#[suggestion_hidden("message", code = "...", applicability = "...")]`
+- `#[suggestion_short("message", code = "...", applicability = "...")]`
+- `#[suggestion_verbose("message", code = "...", applicability = "...")]`
 
 Suggestions must be applied on either a `Span` field or a `(Span,
-MachineApplicability)` field. Similarly to other field attributes, the slug
-specifies the Fluent attribute with the message and defaults to the equivalent
-of `.suggestion`. `code` specifies the code that should be suggested as a
+MachineApplicability)` field. Similarly to other field attributes, a message
+needs to be provided which will be shown to the user.
+`code` specifies the code that should be suggested as a
 replacement and is a format string (e.g. `{field_name}` would be replaced by
-the value of the `field_name` field of the struct), not a Fluent identifier.
+the value of the `field_name` field of the struct).
 `applicability` can be used to specify the applicability in the attribute, it
 cannot be used when the field's type contains an `Applicability`.
 
@@ -119,15 +98,15 @@ In the end, the `Diagnostic` derive will generate an implementation of
 ```rust,ignore
 impl<'a, G: EmissionGuarantee> Diagnostic<'a> for FieldAlreadyDeclared {
     fn into_diag(self, dcx: &'a DiagCtxt, level: Level) -> Diag<'a, G> {
-        let mut diag = Diag::new(dcx, level, fluent::hir_analysis_field_already_declared);
+        let mut diag = Diag::new(dcx, level, "field `{$field_name}` is already declared");
         diag.set_span(self.span);
         diag.span_label(
             self.span,
-            fluent::hir_analysis_label
+            "field already declared"
         );
         diag.span_label(
             self.prev_span,
-            fluent::hir_analysis_previous_decl_label
+            "`{$field_name}` first declared here"
         );
         diag
     }
@@ -150,60 +129,40 @@ tcx.dcx().emit_err(FieldAlreadyDeclared {
 `#[derive(Diagnostic)]` and `#[derive(LintDiagnostic)]` support the
 following attributes:
 
-- `#[diag(slug, code = "...")]`
+- `#[diag("message", code = "...")]`
   - _Applied to struct or enum variant._
   - _Mandatory_
   - Defines the text and error code to be associated with the diagnostic.
-  - Slug (_Mandatory_)
-    - Uniquely identifies the diagnostic and corresponds to its Fluent message,
-      mandatory.
-    - A path to an item in `rustc_errors::fluent`, e.g.
-      `rustc_errors::fluent::hir_analysis_field_already_declared`
-      (`rustc_errors::fluent` is implicit in the attribute, so just
-      `hir_analysis_field_already_declared`).
+  - Message (_Mandatory_)
+    - The diagnostic message which will be shown to the user.
     - See [translation documentation](./translation.md).
   - `code = "..."` (_Optional_)
     - Specifies the error code.
-- `#[note]` or `#[note(slug)]` (_Optional_)
+- `#[note("message")]` (_Optional_)
   - _Applied to struct or struct fields of type `Span`, `Option<()>` or `()`._
   - Adds a note subdiagnostic.
-  - Value is a path to an item in `rustc_errors::fluent` for the note's
-    message.
-    - Defaults to equivalent of `.note`.
+  - Value is the note's message.
   - If applied to a `Span` field, creates a spanned note.
-- `#[help]` or `#[help(slug)]` (_Optional_)
+- `#[help("message")]` (_Optional_)
   - _Applied to struct or struct fields of type `Span`, `Option<()>` or `()`._
   - Adds a help subdiagnostic.
-  - Value is a path to an item in `rustc_errors::fluent` for the note's
-    message.
-    - Defaults to equivalent of `.help`.
+  - Value is the help message.
   - If applied to a `Span` field, creates a spanned help.
-- `#[label]` or `#[label(slug)]` (_Optional_)
+- `#[label("message")]` (_Optional_)
   - _Applied to `Span` fields._
   - Adds a label subdiagnostic.
-  - Value is a path to an item in `rustc_errors::fluent` for the note's
-    message.
-    - Defaults to equivalent of `.label`.
-- `#[warning]` or `#[warning(slug)]` (_Optional_)
+  - Value is the label's message.
+- `#[warning("message")]` (_Optional_)
   - _Applied to struct or struct fields of type `Span`, `Option<()>` or `()`._
   - Adds a warning subdiagnostic.
-  - Value is a path to an item in `rustc_errors::fluent` for the note's
-    message.
-    - Defaults to equivalent of `.warn`.
-- `#[suggestion{,_hidden,_short,_verbose}(slug, code = "...", applicability = "...")]`
+  - Value is the warning's message.
+- `#[suggestion{,_hidden,_short,_verbose}("message", code = "...", applicability = "...")]`
   (_Optional_)
   - _Applied to `(Span, MachineApplicability)` or `Span` fields._
   - Adds a suggestion subdiagnostic.
-  - Slug (_Mandatory_)
-    - A path to an item in `rustc_errors::fluent`, e.g.
-      `rustc_errors::fluent::hir_analysis_field_already_declared`
-      (`rustc_errors::fluent` is implicit in the attribute, so just
-      `hir_analysis_field_already_declared`). Fluent attributes for all messages
-      exist as top-level items in that module (so `hir_analysis_message.attr` is just
-      `attr`).
+  - Message (_Mandatory_)
+    - Value is the suggestion message that will be shown to the user.
     - See [translation documentation](./translation.md).
-    - Defaults to `rustc_errors::fluent::_subdiag::suggestion` (or
-    - `.suggestion` in Fluent).
   - `code = "..."`/`code("...", ...)` (_Mandatory_)
     - One or multiple format strings indicating the code to be suggested as a
       replacement. Multiple values signify multiple possible replacements.
@@ -235,12 +194,12 @@ shown below:
 ```rust
 #[derive(Subdiagnostic)]
 pub enum ExpectedReturnTypeLabel<'tcx> {
-    #[label(hir_analysis_expected_default_return_type)]
+    #[label("expected `()` because of default return type")]
     Unit {
         #[primary_span]
         span: Span,
     },
-    #[label(hir_analysis_expected_return_type)]
+    #[label("expected `{$expected}` because of return type")]
     Other {
         #[primary_span]
         span: Span,
@@ -260,21 +219,9 @@ attribute applied to the struct or each variant, one of:
 - `#[warning(..)]` for defining a warning
 - `#[suggestion{,_hidden,_short,_verbose}(..)]` for defining a suggestion
 
-All of the above must provide a slug as the first positional argument (a path
-to an item in `rustc_errors::fluent::*`). A slug uniquely identifies the
-diagnostic and is also how the compiler knows what error message to emit (in
-the default locale of the compiler, or in the locale requested by the user).
+All of the above must provide a diagnostic message as the first positional argument.
 See [translation documentation](./translation.md) to learn more about how
-translatable error messages are written and how slug items are generated.
-
-In our example, the Fluent message for the "expected return type" label
-looks like this:
-
-```fluent
-hir_analysis_expected_default_return_type = expected `()` because of default return type
-
-hir_analysis_expected_return_type = expected `{$expected}` because of return type
-```
+translatable error messages are generated.
 
 Using the `#[primary_span]` attribute on a field (with type `Span`) will denote
 the primary span of the subdiagnostic. A primary span is only necessary for a
@@ -289,17 +236,15 @@ Like `Diagnostic`, `Subdiagnostic` supports `Option<T>` and
 
 Suggestions can be emitted using one of four attributes on the type/variant:
 
-- `#[suggestion(..., code = "...", applicability = "...")]`
-- `#[suggestion_hidden(..., code = "...", applicability = "...")]`
-- `#[suggestion_short(..., code = "...", applicability = "...")]`
-- `#[suggestion_verbose(..., code = "...", applicability = "...")]`
+- `#[suggestion("...", code = "...", applicability = "...")]`
+- `#[suggestion_hidden("...", code = "...", applicability = "...")]`
+- `#[suggestion_short("...", code = "...", applicability = "...")]`
+- `#[suggestion_verbose("...", code = "...", applicability = "...")]`
 
 Suggestions require `#[primary_span]` be set on a field and can have the
 following sub-attributes:
 
-- The first positional argument specifies the path to a item in
-  `rustc_errors::fluent` corresponding to the Fluent attribute with the message
-  and defaults to the equivalent of `.suggestion`.
+- The first positional argument specifies the message which will be shown to the user.
 - `code` specifies the code that should be suggested as a replacement and is a
   format string (e.g. `{field_name}` would be replaced by the value of the
   `field_name` field of the struct), not a Fluent identifier.
@@ -318,11 +263,11 @@ impl<'tcx> Subdiagnostic for ExpectedReturnTypeLabel<'tcx> {
         use rustc_errors::{Applicability, IntoDiagArg};
         match self {
             ExpectedReturnTypeLabel::Unit { span } => {
-                diag.span_label(span, rustc_errors::fluent::hir_analysis_expected_default_return_type)
+                diag.span_label(span, "expected `()` because of default return type")
             }
             ExpectedReturnTypeLabel::Other { span, expected } => {
                 diag.set_arg("expected", expected);
-                diag.span_label(span, rustc_errors::fluent::hir_analysis_expected_return_type)
+                diag.span_label(span, "expected `{$expected}` because of return type")
             }
         }
     }
@@ -354,7 +299,7 @@ If a subdiagnostic sets a argument with the same name as a arguments already in
 it will report an error at runtime unless both have exactly the same value.
 It has two benefits:
 - preserves the flexibility that arguments in the main diagnostic are allowed to appear in the attributes of the subdiagnostic.
-For example, There is an attribute `#[suggestion(code = "{new_vis}")]` in the subdiagnostic, but `new_vis` is the field in the main diagnostic struct.
+For example, There is an attribute `#[suggestion("...", code = "{new_vis}")]` in the subdiagnostic, but `new_vis` is the field in the main diagnostic struct.
 - prevents accidental overwriting or deletion of arguments required by the main diagnostic or other subdiagnostics.
 
 These rules guarantee that arguments injected by subdiagnostics are strictly scoped to their own rendering.
@@ -364,32 +309,20 @@ Additionally, subdiagnostics can access arguments from the main diagnostic with
 ### Reference for `#[derive(Subdiagnostic)]`
 `#[derive(Subdiagnostic)]` supports the following attributes:
 
-- `#[label(slug)]`, `#[help(slug)]`, `#[warning(slug)]` or `#[note(slug)]`
+- `#[label("message")]`, `#[help("message")]`, `#[warning("message")]` or `#[note("message")]`
   - _Applied to struct or enum variant. Mutually exclusive with struct/enum variant attributes._
   - _Mandatory_
   - Defines the type to be representing a label, help or note.
-  - Slug (_Mandatory_)
-    - Uniquely identifies the diagnostic and corresponds to its Fluent message,
-      mandatory.
-    - A path to an item in `rustc_errors::fluent`, e.g.
-      `rustc_errors::fluent::hir_analysis_field_already_declared`
-      (`rustc_errors::fluent` is implicit in the attribute, so just
-      `hir_analysis_field_already_declared`).
+  - Message (_Mandatory_)
+    - The diagnostic message that will be shown to the user.
     - See [translation documentation](./translation.md).
-- `#[suggestion{,_hidden,_short,_verbose}(slug, code = "...", applicability = "...")]`
+- `#[suggestion{,_hidden,_short,_verbose}("message", code = "...", applicability = "...")]`
   - _Applied to struct or enum variant. Mutually exclusive with struct/enum variant attributes._
   - _Mandatory_
   - Defines the type to be representing a suggestion.
-  - Slug (_Mandatory_)
-    - A path to an item in `rustc_errors::fluent`, e.g.
-      `rustc_errors::fluent::hir_analysis_field_already_declared`
-      (`rustc_errors::fluent` is implicit in the attribute, so just
-      `hir_analysis::field_already_declared`). Fluent attributes for all messages
-      exist as top-level items in that module (so `hir_analysis_message.attr` is just
-      `hir_analysis::attr`).
+  - Message (_Mandatory_)
+    - The diagnostic message that will be shown to the user.
     - See [translation documentation](./translation.md).
-    - Defaults to `rustc_errors::fluent::_subdiag::suggestion` (or
-    - `.suggestion` in Fluent).
   - `code = "..."`/`code("...", ...)` (_Mandatory_)
     - One or multiple format strings indicating the code to be suggested as a
       replacement. Multiple values signify multiple possible replacements.
@@ -401,11 +334,11 @@ Additionally, subdiagnostics can access arguments from the main diagnostic with
       - `maybe-incorrect`
       - `has-placeholders`
       - `unspecified`
-- `#[multipart_suggestion{,_hidden,_short,_verbose}(slug, applicability = "...")]`
+- `#[multipart_suggestion{,_hidden,_short,_verbose}("message", applicability = "...")]`
   - _Applied to struct or enum variant. Mutually exclusive with struct/enum variant attributes._
   - _Mandatory_
   - Defines the type to be representing a multipart suggestion.
-  - Slug (_Mandatory_): see `#[suggestion]`
+  - Message (_Mandatory_): see `#[suggestion]`
   - `applicability = "..."` (_Optional_): see `#[suggestion]`
 - `#[primary_span]` (_Mandatory_ for labels and suggestions; _optional_ otherwise; not applicable
 to multipart suggestions)

src/doc/rustc-dev-guide/src/diagnostics/translation.md

@@ -13,10 +13,7 @@ active redesign proposals (as of
 Please see the tracking issue <https://github.com/rust-lang/rust/issues/132181>
 for status updates.
 
-We have downgraded the internal lints `untranslatable_diagnostic` and
-`diagnostic_outside_of_impl`. Those internal lints previously required new code
-to use the current translation infrastructure. However, because the translation
-infra is waiting for a yet-to-be-proposed redesign and thus rework, we are not
+The translation infra is waiting for a yet-to-be-proposed redesign and thus rework, we are not
 mandating usage of current translation infra. Use the infra if you *want to* or
 otherwise makes the code cleaner, but otherwise sidestep the translation infra
 if you need more flexibility.
@@ -40,11 +37,6 @@ There are two ways of writing translatable diagnostics:
 When adding or changing a translatable diagnostic,
 you don't need to worry about the translations.
 Only updating the original English message is required.
-Currently,
-each crate which defines translatable diagnostics has its own Fluent resource,
-which is a file named `messages.ftl`,
-located in the root of the crate
-(such as`compiler/rustc_expand/messages.ftl`).
 
 ## Fluent
 
@@ -118,11 +110,8 @@ information that needs to be provided by the code to do so.
 
 ### Compile-time validation and typed identifiers
 
-rustc's `fluent_messages` macro performs compile-time validation of Fluent
-resources and generates code to make it easier to refer to Fluent messages in
-diagnostics.
-
-Compile-time validation of Fluent resources will emit any parsing errors
+rustc's `#[derive(Diagnostic)]` macro performs compile-time validation of Fluent
+messages. Compile-time validation of Fluent resources will emit any parsing errors
 from Fluent resources while building the compiler, preventing invalid Fluent
 resources from causing panics in the compiler. Compile-time validation also
 emits an error if multiple Fluent messages have the same identifier.

src/doc/rustc-dev-guide/src/feature-gate-check.md

@@ -0,0 +1,144 @@
+# Feature Gate Checking
+
+For the how-to steps to add, remove, rename, or stabilize feature gates,
+see [Feature gates][feature-gates].
+
+Feature gates prevent usage of unstable language and library features without a
+nightly-only `#![feature(...)]` opt-in. This chapter documents the implementation
+of feature gating: where gates are defined, how they are enabled, and how usage
+is verified.
+
+<!-- data-check: Feb 2026 -->
+
+## Feature Definitions
+
+All feature gate definitions are located in the `rustc_feature` crate:
+
+- **Unstable features** are declared in [`rustc_feature/src/unstable.rs`] via
+  the `declare_features!` macro. This associates features with issue numbers and
+  tracking metadata.
+- **Accepted features** (stabilized) are listed in [`rustc_feature/src/accepted.rs`].
+- **Removed features** (explicitly disallowed) are listed in [`rustc_feature/src/removed.rs`].
+- **Gated built-in attributes and cfgs** are declared in [`rustc_feature/src/builtin_attrs.rs`].
+
+The [`rustc_feature::Features`] type represents the **active feature set** for a
+crate. Helpers like `enabled`, `incomplete`, and `internal` are used during
+compilation to check status.
+
+## Collecting Features
+
+Before AST validation or expansion, `rustc` collects crate-level
+`#![feature(...)]` attributes to build the active `Features` set.
+
+- The collection happens in [`rustc_expand/src/config.rs`] in [`features`].
+- Each `#![feature]` entry is classified against the `unstable`, `accepted`, and
+  `removed` tables:
+  - **Removed** features cause an immediate error.
+  - **Accepted** features are recorded but do not require nightly. On
+    stable/beta, `maybe_stage_features` in
+    [`rustc_ast_passes/src/feature_gate.rs`] emits the non-nightly
+    diagnostic and lists stable features, which is where the "already
+    stabilized" messaging comes from.
+  - **Unstable** features are recorded as enabled.
+  - Unknown features are treated as **library features** and validated later.
+- With `-Z allow-features=...`, any **unstable** or **unknown** feature
+  not in the allowlist is rejected.
+- [`RUSTC_BOOTSTRAP`] feeds into `UnstableFeatures::from_environment`. This
+  variable controls whether the compiler is treated as "nightly", allowing
+  feature gates to be bypassed during bootstrapping or explicitly disabled (`-1`).
+
+## Parser Gating
+
+Some syntax is detected and gated during parsing. The parser records spans for
+later checking to keep diagnostics consistent and deferred until after parsing.
+
+- [`rustc_session/src/parse.rs`] defines [`GatedSpans`] and the `gate` method.
+- The parser uses it in [`rustc_parse/src/parser/*`] when it encounters
+  syntax that requires a gate (e.g., `async for`, `yield`, experimental patterns).
+
+## Checking Pass
+
+The central logic lives in [`rustc_ast_passes/src/feature_gate.rs`], primarily
+in `check_crate` and its AST visitor.
+
+### `check_crate`
+
+`check_crate` performs high-level validation:
+
+- `maybe_stage_features`: Rejects `#![feature]` on stable/beta.
+- `check_incompatible_features`: Ensures incompatible feature combinations
+  (declared in `rustc_feature::INCOMPATIBLE_FEATURES`) are not used together.
+- `check_new_solver_banned_features`: Bans features incompatible with
+  compiler mode for the next trait solver.
+- **Parser-gated spans**: Processes the `GatedSpans` recorded during parsing
+  (see [Checking `GatedSpans`](#checking-gatedspans)).
+
+### Checking `GatedSpans`
+
+`check_crate` iterates over `sess.psess.gated_spans`:
+
+- The `gate_all!` macro emits diagnostics for each gated span if the feature is
+  not enabled.
+- Some gates have extra logic (e.g., `yield` can be allowed by `coroutines` or
+  `gen_blocks`).
+- Legacy gates (e.g., `box_patterns`, `try_blocks`) may use a separate path that
+  emits future-incompatibility warnings instead of hard errors.
+
+### AST Visitor
+
+A `PostExpansionVisitor` walks the expanded AST to check constructs that are
+easier to validate after expansion.
+
+- The visitor uses helper macros (`gate!`, `gate_alt!`, `gate_multi!`) to check:
+  1. Is the feature enabled?
+  2. Does `span.allows_unstable` permit it (for internal compiler macros)?
+- Examples include `trait_alias`, `decl_macro`, `extern types`, and various
+  `impl Trait` forms.
+
+## Attributes and `cfg`
+
+Beyond syntax, rustc also gates attributes and `cfg` options.
+
+### Built-in attributes
+
+- [`rustc_ast_passes::check_attribute`] inspects attributes against
+  `BUILTIN_ATTRIBUTE_MAP`.
+- If the attribute is `AttributeGate::Gated` and the feature isn’t enabled,
+  `feature_err` is emitted.
+
+### `cfg` options
+
+- [`rustc_attr_parsing/src/attributes/cfg.rs`] defines `gate_cfg` and uses
+  [`rustc_feature::find_gated_cfg`] to reject gated `cfg`s.
+- `gate_cfg` respects `Span::allows_unstable`, allowing internal compiler
+  macros to bypass `cfg` gates when marked with `#[allow_internal_unstable]`.
+- The gated cfg list is defined in [`rustc_feature/src/builtin_attrs.rs`].
+
+## Diagnostics
+
+Diagnostic helpers are located in [`rustc_session/src/parse.rs`].
+
+- `feature_err` and `feature_warn` emit standardized diagnostics, attaching the
+  tracking issue number where possible.
+- `Span::allows_unstable` in [`rustc_span/src/lib.rs`] checks if a span originates
+  from a macro marked with `#[allow_internal_unstable]`. This allows internal
+  macros to use unstable features on stable channels while enforcing gates for
+  user code.
+
+[`rustc_feature/src/unstable.rs`]: https://github.com/rust-lang/rust/blob/HEAD/compiler/rustc_feature/src/unstable.rs
+[`rustc_feature/src/removed.rs`]: https://github.com/rust-lang/rust/blob/HEAD/compiler/rustc_feature/src/removed.rs
+[`rustc_feature/src/accepted.rs`]: https://github.com/rust-lang/rust/blob/HEAD/compiler/rustc_feature/src/accepted.rs
+[`rustc_feature/src/builtin_attrs.rs`]: https://github.com/rust-lang/rust/blob/HEAD/compiler/rustc_feature/src/builtin_attrs.rs
+[`rustc_feature::Features`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_feature/struct.Features.html
+[`rustc_expand/src/config.rs`]: https://github.com/rust-lang/rust/blob/HEAD/compiler/rustc_expand/src/config.rs
+[`features`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_expand/config/fn.features.html
+[`RUSTC_BOOTSTRAP`]: https://doc.rust-lang.org/beta/unstable-book/compiler-environment-variables/RUSTC_BOOTSTRAP.html
+[`rustc_session/src/parse.rs`]: https://github.com/rust-lang/rust/blob/HEAD/compiler/rustc_session/src/parse.rs
+[`GatedSpans`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_session/parse/struct.GatedSpans.html
+[`rustc_ast_passes/src/feature_gate.rs`]: https://github.com/rust-lang/rust/blob/HEAD/compiler/rustc_ast_passes/src/feature_gate.rs
+[`rustc_parse/src/parser/*`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_parse/parser/index.html
+[`rustc_ast_passes::check_attribute`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_ast_passes/feature_gate/fn.check_attribute.html
+[`rustc_attr_parsing/src/attributes/cfg.rs`]: https://github.com/rust-lang/rust/blob/HEAD/compiler/rustc_attr_parsing/src/attributes/cfg.rs
+[`rustc_feature::find_gated_cfg`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_feature/fn.find_gated_cfg.html
+[`rustc_span/src/lib.rs`]: https://github.com/rust-lang/rust/blob/HEAD/compiler/rustc_span/src/lib.rs
+[feature-gates]: ./feature-gates.md

src/doc/rustc-dev-guide/src/feature-gate-ck.md

@@ -1,3 +0,0 @@
-# Feature Gate Checking
-
-**TODO**: this chapter [#1158](https://github.com/rust-lang/rustc-dev-guide/issues/1158)

src/doc/rustc-dev-guide/src/feature-gates.md

@@ -3,9 +3,13 @@
 This chapter is intended to provide basic help for adding, removing, and
 modifying feature gates.
 
+For how rustc enforces and checks feature gates in the compiler pipeline,
+see [Feature Gate Checking][feature-gate-check].
+
 Note that this is specific to *language* feature gates; *library* feature gates use [a different
 mechanism][libs-gate].
 
+[feature-gate-check]: ./feature-gate-check.md
 [libs-gate]: ./stability.md
 
 ## Adding a feature gate

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

@@ -372,7 +372,7 @@ to ensure that Git doesn't create merge commits when `git pull`ing, without
 needing to pass `--ff-only` or `--rebase` every time.
 
 You can also `git push --force-with-lease` from main to double-check that your
-feature branches are in sync with their state on the Github side.
+feature branches are in sync with their state on the GitHub side.
 
 ## Advanced Rebasing
 
@@ -494,7 +494,7 @@ to follow and understand.
 
 ### Hiding whitespace
 
-Github has a button for disabling whitespace changes that may be useful.
+GitHub has a button for disabling whitespace changes that may be useful.
 You can also use `git diff -w origin/main` to view changes locally.
 
 ![hide whitespace](./img/github-whitespace-changes.png)
@@ -505,7 +505,7 @@ To checkout PRs locally, you can use `git fetch upstream pull/NNNNN/head && git
 FETCH_HEAD`.
 
 You can also use github's cli tool.
-Github shows a button on PRs where you can copy-paste the command to check it out locally.
+GitHub shows a button on PRs where you can copy-paste the command to check it out locally.
 See <https://cli.github.com/> for more info.
 
 ![`gh` suggestion](./img/github-cli.png)
@@ -521,7 +521,7 @@ for more details.
 
 ### Moving large sections of code
 
-Git and Github's default diff view for large moves *within* a file is quite poor; it will show each
+Git and GitHub's default diff view for large moves *within* a file is quite poor; it will show each
 line as deleted and each line as added, forcing you to compare each line yourself.
 Git has an option to show moved lines in a different color:
 
@@ -562,7 +562,7 @@ Rust projects from within the `rust` repo.
 Examples include Rust's fork of
 `llvm-project`, `cargo`, and libraries like `stdarch` and `backtrace`.
 
-Those projects are developed and maintained in an separate Git (and GitHub)
+Those projects are developed and maintained in a separate Git (and GitHub)
 repository, and they have their own Git history/commits, issue tracker and PRs.
 Submodules allow us to create some sort of embedded sub-repository inside the
 `rust` repository and use them like they were directories in the `rust` repository.

src/doc/rustc-dev-guide/src/macro-expansion.md

@@ -468,7 +468,7 @@ Here `$mvar` is called a _metavariable_. Unlike normal variables, rather than
 binding to a value _at runtime_, a metavariable binds _at compile time_ to a
 tree of _tokens_.  A _token_ is a single "unit" of the grammar, such as an
 identifier (e.g. `foo`) or punctuation (e.g. `=>`). There are also other
-special tokens, such as `EOF`, which its self indicates that there are no more
+special tokens, such as `EOF`, which itself indicates that there are no more
 tokens. There are token trees resulting from the paired parentheses-like
 characters (`(`...`)`, `[`...`]`, and `{`...`}`) – they include the open and
 close and all the tokens in between (Rust requires that parentheses-like

src/doc/rustc-dev-guide/src/notification-groups/about.md

@@ -11,7 +11,7 @@ that fits the notification group's criteria. If you are interested, you
 can then [claim the issue] and start working on it.
 
 Of course, you don't have to wait for new issues to be tagged! If you
-prefer, you can use the Github label for a notification group to
+prefer, you can use the GitHub label for a notification group to
 search for existing issues that haven't been claimed yet.
 
 [claim the issue]: https://forge.rust-lang.org/triagebot/issue-assignment.html
@@ -47,7 +47,7 @@ particularly those of **middle priority**:
 ## Joining a notification group
 
 To join a notification group, you just have to open a PR adding your
-Github username to the appropriate file in the Rust team repository.
+GitHub username to the appropriate file in the Rust team repository.
 See the "example PRs" below to get a precise idea and to identify the
 file to edit.
 

src/doc/rustc-dev-guide/src/notification-groups/apple.md

@@ -1,6 +1,6 @@
 # Apple notification group
 
-**Github Labels:** [O-macos], [O-ios], [O-tvos], [O-watchos] and [O-visionos] <br>
+**GitHub Labels:** [O-macos], [O-ios], [O-tvos], [O-watchos] and [O-visionos] <br>
 **Ping command:** `@rustbot ping apple`
 
 This list will be used to ask for help both in diagnosing and testing

src/doc/rustc-dev-guide/src/notification-groups/arm.md

@@ -1,6 +1,6 @@
 # ARM notification group
 
-**Github Label:** [O-ARM] <br>
+**GitHub Label:** [O-ARM] <br>
 **Ping command:** `@rustbot ping arm`
 
 [O-ARM]: https://github.com/rust-lang/rust/labels/O-ARM

src/doc/rustc-dev-guide/src/notification-groups/emscripten.md

@@ -1,6 +1,6 @@
 # Emscripten notification group
 
-**Github Label:** [O-emscripten] <br>
+**GitHub Label:** [O-emscripten] <br>
 **Ping command:** `@rustbot ping emscripten`
 
 [O-emscripten]: https://github.com/rust-lang/rust/labels/O-emscripten

src/doc/rustc-dev-guide/src/notification-groups/fuchsia.md

@@ -1,6 +1,6 @@
 # Fuchsia notification group
 
-**Github Label:** [O-fuchsia] <br>
+**GitHub Label:** [O-fuchsia] <br>
 **Ping command:** `@rustbot ping fuchsia`
 
 [O-fuchsia]: https://github.com/rust-lang/rust/labels/O-fuchsia

src/doc/rustc-dev-guide/src/notification-groups/loongarch.md

@@ -1,6 +1,6 @@
 # LoongArch notification group
 
-**Github Label:** [O-loongarch] <br>
+**GitHub Label:** [O-loongarch] <br>
 **Ping command:** `@rustbot ping loongarch`
 
 [O-loongarch]: https://github.com/rust-lang/rust/labels/O-loongarch

src/doc/rustc-dev-guide/src/notification-groups/risc-v.md

@@ -1,6 +1,6 @@
 # RISC-V notification group
 
-**Github Label:** [O-riscv] <br>
+**GitHub Label:** [O-riscv] <br>
 **Ping command:** `@rustbot ping risc-v`
 
 [O-riscv]: https://github.com/rust-lang/rust/labels/O-riscv

src/doc/rustc-dev-guide/src/notification-groups/rust-for-linux.md

@@ -1,6 +1,6 @@
 # Rust for Linux notification group
 
-**Github Label:** [A-rust-for-linux] <br>
+**GitHub Label:** [A-rust-for-linux] <br>
 **Ping command:** `@rustbot ping rfl`
 
 [A-rust-for-linux]: https://github.com/rust-lang/rust/labels/A-rust-for-linux

src/doc/rustc-dev-guide/src/notification-groups/wasi.md

@@ -1,6 +1,6 @@
 # WASI notification group
 
-**Github Label:** [O-wasi] <br>
+**GitHub Label:** [O-wasi] <br>
 **Ping command:** `@rustbot ping wasi`
 
 [O-wasi]: https://github.com/rust-lang/rust/labels/O-wasi

src/doc/rustc-dev-guide/src/notification-groups/wasm.md

@@ -1,6 +1,6 @@
 # WebAssembly (WASM) notification group
 
-**Github Label:** [O-wasm] <br>
+**GitHub Label:** [O-wasm] <br>
 **Ping command:** `@rustbot ping wasm`
 
 [O-wasm]: https://github.com/rust-lang/rust/labels/O-wasm

src/doc/rustc-dev-guide/src/notification-groups/windows.md

@@ -1,6 +1,6 @@
 # Windows notification group
 
-**Github Label:** [O-Windows] <br>
+**GitHub Label:** [O-Windows] <br>
 **Ping command:** `@rustbot ping windows`
 
 [O-Windows]: https://github.com/rust-lang/rust/labels/O-Windows

src/doc/rustc-dev-guide/src/offload/internals.md

@@ -8,9 +8,15 @@ also offer more advanced, possibly unsafe, interfaces which allow a higher degre
 The implementation is based on LLVM's "offload" project, which is already used by OpenMP to run Fortran or C++ code on GPUs.
 While the project is under development, users will need to call other compilers like clang to finish the compilation process.
 
-## High-level design:
+## High-level compilation design:
 We use a single-source, two-pass compilation approach. 
 
 First we compile all functions that should be offloaded for the device (e.g nvptx64, amdgcn-amd-amdhsa, intel in the future). Currently we require cumbersome `#cfg(target_os="")` annotations, but we intend to recognize those in the future based on our offload intrinsic. 
+This first compilation currently does not leverage rustc's internal Query system, so it will always recompile your kernels at the moment. This should be easy to fix, but we prioritize features and runtime performance improvements at the moment. Please reach out if you want to implement it, though!
 
 We then compile the code for the host (e.g. x86-64), where most of the offloading logic happens. On the host side, we generate calls to the openmp offload runtime, to inform it about the layout of the types (a simplified version of the autodiff TypeTrees). We also use the type system to figure out whether kernel arguments have to be moved only to the device (e.g. `&[f32;1024]`), from the device, or both (e.g. `&mut [f64]`). We then launch the kernel, after which we inform the runtime to end this environment and move data back (as far as needed).
+
+The second pass for the host will load the kernel artifacts from the previous compilation. rustc in general may not "guess" or hardcode the build directory layout, and as such it must be told the path to the kernel artifacts in the second invocation. The logic for this could be integrated into cargo, but it also only requires a trivial cargo wrapper, which we could trivially provide via crates.io till we see larger adoption.
+
+It might seem tempting to think about a single-source, single pass compilation approach. However, a lot of the rustc frontend (e.g. AST) will drop any dead code (e.g. code behind an inactive `cfg`). Getting the frontend to expand and lower code for two targets naively will result in multiple definitions of the same symbol (and other issues). Trying to teach the whole rustc middle and backend to be aware that any symbol now might contain two implementations is a large undertaking, and it is questionable why we should make the whole compiler more complex, if the alternative is a ~5 line cargo wrapper. We still control the full compilation pipeline and have both host and device code available, therefore there shouldn't be a runtime performance difference between the two approaches. 
+

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

@@ -198,7 +198,7 @@ satisfy/optimize for. For example,
   the input programs says they do, and should continue to do so despite the
   tremendous amount of change constantly going on.
 - Integration: a number of other tools need to use the compiler in
-  various ways (e.g. `cargo`, `clippy`, `MIRI`) that must be supported.
+  various ways (e.g. `cargo`, `clippy`, `Miri`) that must be supported.
 - Compiler stability: the compiler should not crash or fail ungracefully on the
   stable channel.
 - Rust stability: the compiler must respect Rust's stability guarantees by not
@@ -245,7 +245,7 @@ for different purposes:
   values). `MIR` is used for borrow checking and other
   important dataflow-based checks, such as checking for uninitialized values.
   It is also used for a series of optimizations and for constant evaluation (via
-  `MIRI`). Because `MIR` is still generic, we can do a lot of analyses here more
+  `Miri`). Because `MIR` is still generic, we can do a lot of analyses here more
   efficiently than after monomorphization.
 - `LLVM-IR`: This is the standard form of all input to the LLVM compiler. `LLVM-IR`
   is a sort of typed assembly language with lots of annotations. It's
@@ -395,7 +395,7 @@ For more details on bootstrapping, see
 - Lexical Analysis: Lex the user program to a stream of tokens
   - Guide: [Lexing and Parsing](the-parser.md)
   - Lexer definition: [`rustc_lexer`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_lexer/index.html)
-  - Main entry point: [`rustc_lexer::cursor::Cursor::advance_token`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_lexer/cursor/struct.Cursor.html#method.advance_token)
+  - Main entry point: [`rustc_lexer::Cursor::advance_token`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_lexer/struct.Cursor.html#method.advance_token)
 - Parsing: Parse the stream of tokens to an Abstract Syntax Tree (AST)
   - Guide: [Lexing and Parsing](the-parser.md)
   - Guide: [Macro Expansion](macro-expansion.md)

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

@@ -254,8 +254,8 @@ You will typically need to:
 An example of introducing such a cross-crate query can be found in commit [`996a185`](https://github.com/rust-lang/rust/commit/996a185) in the `rust-lang/rust` repository.
 
 [rustc_metadata]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_metadata/index.html
-[providers_struct]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/query/struct.Providers.html
-[extern_providers_struct]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/query/struct.ExternProviders.html
+[providers_struct]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/queries/struct.Providers.html
+[extern_providers_struct]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/queries/struct.ExternProviders.html
 
 ---
 

src/doc/rustc-dev-guide/src/syntax-intro.md

@@ -13,7 +13,7 @@ And parsing requires macro expansion, which in turn may require parsing the outp
 
 [AST]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_parse/index.html
 [macro expansion]: ./macro-expansion.md
-[feature-gate checking]: ./feature-gate-ck.md
+[feature-gate checking]: ./feature-gate-check.md
 [lexing, parsing]: ./the-parser.md
 [name resolution]: ./name-resolution.md
 [validation]: ./ast-validation.md

src/doc/rustc-dev-guide/src/tests/ci.md

@@ -102,7 +102,7 @@ Most platforms only run the build steps, some run a restricted set of tests;
 only a subset run the full suite of tests (see Rust's [platform tiers]).
 
 Auto jobs are defined in the `auto` section of [`jobs.yml`].
-They are executed on the `auto` branch under the `rust-lang/rust` repository,
+They are executed on the [`automation/bors/auto`][auto] branch under the `rust-lang/rust` repository,
 and the final result will be reported via a comment made by bors on the corresponding PR.
 The live results can be seen on [the GitHub Actions workflows page].
 
@@ -110,6 +110,7 @@ At any given time, at most a single `auto` build is being executed.
 Find out more in [Merging PRs serially with bors](#merging-prs-serially-with-bors).
 
 [platform tiers]: https://forge.rust-lang.org/release/platform-support.html#rust-platform-support
+[auto]: https://github.com/rust-lang/rust/tree/automation/bors/auto
 
 ### Try builds
 
@@ -204,7 +205,7 @@ to help make the perf comparison as fair as possible.
 > However, it can be less flexible because you cannot adjust the set of tests
 > that are exercised this way.
 
-Try builds are executed on the `try` branch under the `rust-lang/rust` repository and
+Try builds are executed on the [`automation/bors/try`][try] branch under the `rust-lang/rust` repository and
 their results can be seen on [the GitHub Actions workflows page],
 although usually you will be notified of the result by a comment made by bors on
 the corresponding PR.
@@ -213,6 +214,7 @@ Multiple try builds can execute concurrently across different PRs, but there can
 a single try build running on a single PR at any given time.
 
 [rustc-perf]: https://github.com/rust-lang/rustc-perf
+[try]: https://github.com/rust-lang/rust/tree/automation/bors/try
 
 ### Modifying CI jobs
 
@@ -284,8 +286,8 @@ If all the builders are green, the PR is merged, otherwise the failure is
 recorded and the PR will have to be re-approved again.
 
 Bors doesn’t interact with CI services directly, but it works by pushing the
-merge commit it wants to test to specific branches (like `auto` or `try`), which
-are configured to execute CI checks.
+merge commit it wants to test to specific branches (like `automation/bors/auto` or `automation/bors/try`),
+which are configured to execute CI checks.
 Bors then detects the outcome of the build by listening for either Commit Statuses or Check Runs.
 Since the merge commit is
 based on the latest `main` and only one can be tested at the same time, when
@@ -447,8 +449,8 @@ If you want to determine which `bootstrap.toml` settings are used in CI for a
 particular job, it is probably easiest to just look at the build log.
 To do this:
 
-1. Go to <https://github.com/rust-lang/rust/actions?query=branch%3Aauto+is%3Asuccess>
-   to find the most recently successful build, and click on it.
+1. Go to [the Rust CI successful workflow runs page][workflow runs]
+   and click on the most recent one.
 2. Choose the job you are interested in on the left-hand side.
 3. Click on the gear icon and choose "View raw logs"
 4. Search for the string "Configure the build"
@@ -462,3 +464,4 @@ To do this:
 [merge queue]: https://bors.rust-lang.org/queue/rust
 [dist-x86_64-linux]: https://github.com/rust-lang/rust/blob/HEAD/src/ci/docker/host-x86_64/dist-x86_64-linux/Dockerfile
 [the GitHub Actions workflows page]: https://github.com/rust-lang/rust/actions
+[workflow runs]: https://github.com/rust-lang/rust/actions?query=branch%3Aautomation%2Fbors%2Fauto+is%3Asuccess

src/doc/rustc-dev-guide/src/ty-module/binders.md

@@ -48,5 +48,5 @@ This would cause all kinds of issues as the region `'^1_0` refers to a binder at
 
 [`Binder`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/struct.Binder.html
 [`BoundVar`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/struct.BoundVar.html
-[`BoundRegionKind`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/enum.BoundRegionKind.html
-[`BoundTyKind`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/enum.BoundTyKind.html
+[`BoundRegionKind`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/type.BoundRegionKind.html
+[`BoundTyKind`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/type.BoundTyKind.html

src/doc/rustc-dev-guide/src/ty-module/instantiating-binders.md

@@ -136,7 +136,7 @@ As a concrete example, accessing the signature of a function we are type checkin
 
 [`liberate_late_bound_regions`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/context/struct.TyCtxt.html#method.liberate_late_bound_regions
 [representing-types]: param-ty-const-regions.md
-[`BoundRegionKind`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/enum.BoundRegionKind.html
+[`BoundRegionKind`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/type.BoundRegionKind.html
 [`enter_forall`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_trait_selection/infer/struct.InferCtxt.html#method.enter_forall
 [ch_placeholders_universes]: ../borrow-check/region-inference/placeholders-and-universes.md
 [`instantiate_binder_with_fresh_vars`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_trait_selection/infer/struct.InferCtxt.html#method.instantiate_binder_with_fresh_vars

src/doc/rustc-dev-guide/src/ty-module/param-ty-const-regions.md

@@ -88,7 +88,7 @@ fn foo<'a, 'b, T: 'a>(one: T, two: &'a &'b u32) -> &'b u32 {
 [ch_early_late_bound]: ../early-late-parameters.md
 [ch_binders]: ./binders.md
 [ch_instantiating_binders]: ./instantiating-binders.md
-[`BoundRegionKind`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/enum.BoundRegionKind.html
+[`BoundRegionKind`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/type.BoundRegionKind.html
 [`RegionKind::EarlyParam`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/type.RegionKind.html#variant.ReEarlyParam
 [`RegionKind::LateParam`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/type.RegionKind.html#variant.ReLateParam
 [`ConstKind::Param`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/type.ConstKind.html#variant.Param

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

@@ -5,7 +5,7 @@ The `ty` module defines how the Rust compiler represents types internally. It al
 
 ## `ty::Ty`
 
-When we talk about how rustc represents types,  we usually refer to a type called `Ty` . There are
+When we talk about how rustc represents types, we usually refer to a type called `Ty`. There are
 quite a few modules and types for `Ty` in the compiler ([Ty documentation][ty]).
 
 [ty]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/index.html
@@ -46,7 +46,7 @@ That is, they have two different [`Span`s][span] (locations).
 In addition, HIR might have information left out. This type
 `&u32` is incomplete, since in the full Rust type there is actually a lifetime, but we didn’t need
 to write those lifetimes. There are also some elision rules that insert information. The result may
-look like  `fn foo<'a>(x: &'a u32) -> &'a u32`.
+look like `fn foo<'a>(x: &'a u32) -> &'a u32`.
 
 In the HIR level, these things are not spelled out and you can say the picture is rather incomplete.
 However, at the `ty::Ty` level, these details are added and it is complete. Moreover, we will have

src/doc/rustc-dev-guide/triagebot.toml

@@ -5,6 +5,7 @@
 new_issue = true
 exclude_labels = [
     "A-diagnostics",
+    "C-date-reference-triage",
     "C-tracking-issue",
 ]
 
@@ -84,6 +85,7 @@ does not need reviews. You can request a review using `r? rustc-dev-guide` or \
 rustc-dev-guide = [
     "@BoxyUwU",
     "@jyn514",
+    "@reddevilmidzy",
     "@tshepang",
 ]