diff --git a/rust-version b/rust-version index 4dedd81b0..db9492636 100644 --- a/rust-version +++ b/rust-version @@ -1 +1 @@ -e7d90c695a39426baf5ae705de2f9570a72229de +eda4fc7733ee89e484d7120cafbd80dcb2fce66e diff --git a/src/compiler-debugging.md b/src/compiler-debugging.md index d4c599a6e..25f7eb27e 100644 --- a/src/compiler-debugging.md +++ b/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. diff --git a/src/diagnostics/diagnostic-structs.md b/src/diagnostics/diagnostic-structs.md index a99f6a284..a3a7a1125 100644 --- a/src/diagnostics/diagnostic-structs.md +++ b/src/diagnostics/diagnostic-structs.md @@ -1,6 +1,6 @@ # 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 @@ -8,12 +8,12 @@ don't require much logic in deciding whether or not to add additional subdiagnos 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._ diff --git a/src/diagnostics/translation.md b/src/diagnostics/translation.md index 88526ec1c..cf95727e2 100644 --- a/src/diagnostics/translation.md +++ b/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.