Auto merge of #153416 - JonathanBrouwer:rollup-eezxWTV, r=JonathanBrouwer

Rollup of 12 pull requests



Successful merges:

 - rust-lang/rust#153402 (miri subtree update)
 - rust-lang/rust#152164 (Lint unused features)
 - rust-lang/rust#152801 (Refactor WriteBackendMethods a bit)
 - rust-lang/rust#153196 (Update path separators to be available in const context)
 - rust-lang/rust#153204 (Add `#[must_use]` attribute to `HashMap` and `HashSet` constructors)
 - rust-lang/rust#153317 (Abort after `representability` errors)
 - rust-lang/rust#153276 (Remove `cycle_fatal` query modifier)
 - rust-lang/rust#153300 (Tweak some of our internal `#[rustc_*]` TEST attributes)
 - rust-lang/rust#153396 (use `minicore` in some `run-make` tests)
 - rust-lang/rust#153401 (Migrationg of `LintDiagnostic` - part 7)
 - rust-lang/rust#153406 (Remove a ping for myself)
 - rust-lang/rust#153414 (Rename translation -> formatting)

Author: bors

src/compiler-debugging.md

@@ -275,16 +275,16 @@ Here are some notable ones:
 |----------------|-------------|
 | `rustc_def_path` | Dumps the [`def_path_str`] of an item. |
 | `rustc_dump_def_parents` | Dumps the chain of `DefId` parents of certain definitions. |
+| `rustc_dump_inferred_outlives` | Dumps implied bounds of an item. More precisely, the [`inferred_outlives_of`] an item. |
 | `rustc_dump_item_bounds` | Dumps the [`item_bounds`] of an item. |
+| `rustc_dump_object_lifetime_defaults` | Dumps the [object lifetime defaults] of an item. |
 | `rustc_dump_predicates` | Dumps the [`predicates_of`] an item. |
+| `rustc_dump_variances` | Dumps the [variances] of an item. |
 | `rustc_dump_vtable` | Dumps the vtable layout of an impl, or a type alias of a dyn type. |
 | `rustc_hidden_type_of_opaques` | Dumps the [hidden type of each opaque types][opaq] in the crate. |
 | `rustc_layout` | [See this section](#debugging-type-layouts). |
-| `rustc_object_lifetime_default` | Dumps the [object lifetime defaults] of an item. |
-| `rustc_outlives` | Dumps implied bounds of an item. More precisely, the [`inferred_outlives_of`] an item. |
 | `rustc_regions` | Dumps NLL closure region requirements. |
 | `rustc_symbol_name` | Dumps the mangled & demangled [`symbol_name`] of an item. |
-| `rustc_variances` | Dumps the [variances] of an item. |
 
 Right below you can find elaborate explainers on a selected few.
 

src/diagnostics/diagnostic-structs.md

@@ -1,19 +1,19 @@
 # Diagnostic and subdiagnostic structs
-rustc has three diagnostic traits that can be used to create diagnostics:
-`Diagnostic`, `LintDiagnostic`, and `Subdiagnostic`.
+rustc has two diagnostic traits that can be used to create diagnostics:
+`Diagnostic` and `Subdiagnostic`.
 
 For simple diagnostics,
 derived impls can be used, e.g. `#[derive(Diagnostic)]`. They are only suitable for simple diagnostics that
 don't require much logic in deciding whether or not to add additional subdiagnostics.
 
 In cases where diagnostics require more complex or dynamic behavior, such as conditionally adding subdiagnostics,
 customizing the rendering logic, or selecting messages at runtime, you will need to manually implement
-the corresponding trait (`Diagnostic`, `LintDiagnostic`, or `Subdiagnostic`).
+the corresponding trait (`Diagnostic` 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.
 
-## `#[derive(Diagnostic)]` and `#[derive(LintDiagnostic)]`
+## `#[derive(Diagnostic)]`
 
 Consider the [definition][defn] of the "field already declared" diagnostic shown below:
 
@@ -123,8 +123,8 @@ tcx.dcx().emit_err(FieldAlreadyDeclared {
 });
 ```
 
-### Reference for `#[derive(Diagnostic)]` and `#[derive(LintDiagnostic)]`
-`#[derive(Diagnostic)]` and `#[derive(LintDiagnostic)]` support the following attributes:
+### Reference for `#[derive(Diagnostic)]`
+`#[derive(Diagnostic)]` supports the following attributes:
 
 - `#[diag("message", code = "...")]`
   - _Applied to struct or enum variant._
@@ -171,7 +171,6 @@ tcx.dcx().emit_err(FieldAlreadyDeclared {
   - Adds the subdiagnostic represented by the subdiagnostic struct.
 - `#[primary_span]` (_Optional_)
   - _Applied to `Span` fields on `Subdiagnostic`s.
-    Not used for `LintDiagnostic`s._
   - Indicates the primary span of the diagnostic.
 - `#[skip_arg]` (_Optional_)
   - _Applied to any field._

src/diagnostics/translation.md

@@ -32,7 +32,7 @@ There are two ways of writing translatable diagnostics:
    deciding to emit subdiagnostics and can therefore be represented as diagnostic structs).
    See [the diagnostic and subdiagnostic structs documentation](./diagnostic-structs.md).
 2. Using typed identifiers with `Diag` APIs (in
-   `Diagnostic` or `Subdiagnostic` or `LintDiagnostic` implementations).
+   `Diagnostic` or `Subdiagnostic` implementations).
 
 When adding or changing a translatable diagnostic,
 you don't need to worry about the translations.