rust/compiler/rustc_hir_analysis/src/structured_errors, branch 1.78.0

Rename `StructuredDiagnostic` as `StructuredDiag`.

2024-03-05T01:15:12+00:00

Rename `DiagnosticBuilder` as `Diag`.

2024-02-27T21:55:35+00:00

Much better! Note that this involves renaming (and updating the value of) `DIAGNOSTIC_BUILDER` in clippy.

Prefer `DiagnosticBuilder` over `Diagnostic` in diagnostic modifiers.

2024-02-19T09:23:20+00:00

There are lots of functions that modify a diagnostic. This can be via a `&mut Diagnostic` or a `&mut DiagnosticBuilder`, because the latter type wraps the former and impls `DerefMut`. This commit converts all the `&mut Diagnostic` occurrences to `&mut DiagnosticBuilder`. This is a step towards greatly simplifying `Diagnostic`. Some of the relevant function are made generic, because they deal with both errors and warnings. No function bodies are changed, because all the modifier methods are available on both `Diagnostic` and `DiagnosticBuilder`.

By tracking import use types to check whether it is scope uses or the other situations like module-relative uses, we can do more accurate redundant import checking.

2024-02-18T08:38:11+00:00

fixes #117448 For example unnecessary imports in std::prelude that can be eliminated: ```rust use std::option::Option::Some;//~ WARNING the item `Some` is imported redundantly use std::option::Option::None; //~ WARNING the item `None` is imported redundantly ```

hir: Remove `hir::Map::{opt_parent_id,parent_id,get_parent,find_parent}`

2024-02-10T09:24:46+00:00

hir: Remove `fn opt_hir_id` and `fn opt_span`

2024-02-07T06:38:24+00:00

Stop using `String` for error codes.

2024-01-28T20:41:41+00:00

Error codes are integers, but `String` is used everywhere to represent them. Gross! This commit introduces `ErrCode`, an integral newtype for error codes, replacing `String`. It also introduces a constant for every error code, e.g. `E0123`, and removes the `error_code!` macro. The constants are imported wherever used with `use rustc_errors::codes::*`. With the old code, we have three different ways to specify an error code at a use point: ``` error_code!(E0123) // macro call struct_span_code_err!(dcx, span, E0123, "msg"); // bare ident arg to macro call \#[diag(name, code = "E0123")] // string struct Diag; ``` With the new code, they all use the `E0123` constant. ``` E0123 // constant struct_span_code_err!(dcx, span, E0123, "msg"); // constant \#[diag(name, code = E0123)] // constant struct Diag; ``` The commit also changes the structure of the error code definitions: - `rustc_error_codes` now just defines a higher-order macro listing the used error codes and nothing else. - Because that's now the only thing in the `rustc_error_codes` crate, I moved it into the `lib.rs` file and removed the `error_codes.rs` file. - `rustc_errors` uses that macro to define everything, e.g. the error code constants and the `DIAGNOSTIC_TABLES`. This is in its new `codes.rs` file.

Rework how diagnostic lints are stored.

2024-01-14T03:04:25+00:00

`Diagnostic::code` has the type `DiagnosticId`, which has `Error` and `Lint` variants. Plus `Diagnostic::is_lint` is a bool, which should be redundant w.r.t. `Diagnostic::code`. Seems simple. Except it's possible for a lint to have an error code, in which case its `code` field is recorded as `Error`, and `is_lint` is required to indicate that it's a lint. This is what happens with `derive(LintDiagnostic)` lints. Which means those lints don't have a lint name or a `has_future_breakage` field because those are stored in the `DiagnosticId::Lint`. It's all a bit messy and confused and seems unintentional. This commit: - removes `DiagnosticId`; - changes `Diagnostic::code` to `Option`, which means both errors and lints can straightforwardly have an error code; - changes `Diagnostic::is_lint` to `Option`, where `IsLint` is a new type containing a lint name and a `has_future_breakage` bool, so all lints can have those, error code or not.

Rename consuming chaining methods on `DiagnosticBuilder`.

2024-01-09T20:40:00+00:00

In #119606 I added them and used a `_mv` suffix, but that wasn't great. A `with_` prefix has three different existing uses. - Constructors, e.g. `Vec::with_capacity`. - Wrappers that provide an environment to execute some code, e.g. `with_session_globals`. - Consuming chaining methods, e.g. `Span::with_{lo,hi,ctxt}`. The third case is exactly what we want, so this commit changes `DiagnosticBuilder::foo_mv` to `DiagnosticBuilder::with_foo`. Thanks to @compiler-errors for the suggestion.

Remove all eight `DiagnosticBuilder::*_with_code` methods.

2024-01-08T05:00:34+00:00

These all have relatively low use, and can be perfectly emulated with a simpler construction method combined with `code` or `code_mv`.