about summary refs log tree commit diff
path: root/compiler/rustc_hir_analysis/src/structured_errors
AgeCommit message (Collapse)AuthorLines
2024-07-08Remove `structured_errors` moduleOli Scherer-1138/+0
2024-07-08Remove `StructuredDiag`Oli Scherer-33/+29
2024-07-08Remove another `StructuredDiag` implOli Scherer-57/+0
2024-07-04Remove a use of `StructuredDiag`, which is incompatible with automatic error ↵Oli Scherer-56/+0
tainting and error translations
2024-05-30Rename HIR `TypeBinding` to `AssocItemConstraint` and related cleanupLeón Orell Valerian Liehr-4/+8
2024-05-09Rename Generics::params to Generics::own_paramsMichael Goulet-3/+3
2024-03-17Suggest _ for missing generic arguments in turbofishKornel-6/+25
2024-03-05Rename `StructuredDiagnostic` as `StructuredDiag`.Nicholas Nethercote-6/+6
2024-02-28Rename `DiagnosticBuilder` as `Diag`.Nicholas Nethercote-22/+22
Much better! Note that this involves renaming (and updating the value of) `DIAGNOSTIC_BUILDER` in clippy.
2024-02-19Prefer `DiagnosticBuilder` over `Diagnostic` in diagnostic modifiers.Nicholas Nethercote-14/+14
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`.
2024-02-18By tracking import use types to check whether it is scope uses or the other ↵surechen-5/+3
situations like module-relative uses, we can do more accurate redundant import checking. 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 ```
2024-02-10hir: Remove `hir::Map::{opt_parent_id,parent_id,get_parent,find_parent}`Vadim Petrochenkov-4/+2
2024-02-07hir: Remove `fn opt_hir_id` and `fn opt_span`Vadim Petrochenkov-2/+1
2024-01-29Stop using `String` for error codes.Nicholas Nethercote-9/+11
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.
2024-01-14Rework how diagnostic lints are stored.Nicholas Nethercote-8/+6
`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<String>`, which means both errors and lints can straightforwardly have an error code; - changes `Diagnostic::is_lint` to `Option<IsLint>`, 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.
2024-01-10Rename consuming chaining methods on `DiagnosticBuilder`.Nicholas Nethercote-1/+1
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.
2024-01-08Remove all eight `DiagnosticBuilder::*_with_code` methods.Nicholas Nethercote-2/+1
These all have relatively low use, and can be perfectly emulated with a simpler construction method combined with `code` or `code_mv`.
2023-12-24Remove `Session` methods that duplicate `DiagCtxt` methods.Nicholas Nethercote-3/+3
Also add some `dcx` methods to types that wrap `TyCtxt`, for easier access.
2023-12-23Give `DiagnosticBuilder` a default type.Nicholas Nethercote-16/+9
`IntoDiagnostic` defaults to `ErrorGuaranteed`, because errors are the most common diagnostic level. It makes sense to do likewise for the closely-related (and much more widely used) `DiagnosticBuilder` type, letting us write `DiagnosticBuilder<'a, ErrorGuaranteed>` as just `DiagnosticBuilder<'a>`. This cuts over 200 lines of code due to many multi-line things becoming single line things.
2023-12-12Move some methods from `tcx.hir()` to `tcx`zetanumbers-5/+4
Renamings: - find -> opt_hir_node - get -> hir_node - find_by_def_id -> opt_hir_node_by_def_id - get_by_def_id -> hir_node_by_def_id Fix rebase changes using removed methods Use `tcx.hir_node_by_def_id()` whenever possible in compiler Fix clippy errors Fix compiler Apply suggestions from code review Co-authored-by: Vadim Petrochenkov <vadim.petrochenkov@gmail.com> Add FIXME for `tcx.hir()` returned type about its removal Simplify with with `tcx.hir_node_by_def_id`
2023-10-25Rollup merge of #116553 - gurry:116464-assoc-type-invalid-suggestion, ↵Matthias Krüger-13/+57
r=compiler-errors Do not suggest 'Trait<Assoc=arg>' when in trait impl Fixes #116464 We now skip the suggestion if we're in an impl of the trait.
2023-10-25Do not suggest 'Trait<Assoc=arg>' when in trait implGurinder Singh-14/+58
because that would be illegal syntax
2023-10-13Format all the let chains in compilerMichael Goulet-25/+32
2023-08-06lower impl const to bind to host effect paramDeadbeef-0/+3
2023-07-25inline format!() args from rustc_codegen_llvm to the end (4)Matthias Krüger-6/+6
r? @WaffleLapkin
2023-07-12Re-format let-else per rustfmt updateMark Rousskov-23/+32
2023-05-24Use `Option::is_some_and` and `Result::is_ok_and` in the compilerMaybe Waffle-1/+1
2023-05-03Restrict `From<S>` for `{D,Subd}iagnosticMessage`.Nicholas Nethercote-11/+11
Currently a `{D,Subd}iagnosticMessage` can be created from any type that impls `Into<String>`. That includes `&str`, `String`, and `Cow<'static, str>`, which are reasonable. It also includes `&String`, which is pretty weird, and results in many places making unnecessary allocations for patterns like this: ``` self.fatal(&format!(...)) ``` This creates a string with `format!`, takes a reference, passes the reference to `fatal`, which does an `into()`, which clones the reference, doing a second allocation. Two allocations for a single string, bleh. This commit changes the `From` impls so that you can only create a `{D,Subd}iagnosticMessage` from `&str`, `String`, or `Cow<'static, str>`. This requires changing all the places that currently create one from a `&String`. Most of these are of the `&format!(...)` form described above; each one removes an unnecessary static `&`, plus an allocation when executed. There are also a few places where the existing use of `&String` was more reasonable; these now just use `clone()` at the call site. As well as making the code nicer and more efficient, this is a step towards possibly using `Cow<'static, str>` in `{D,Subd}iagnosticMessage::{Str,Eager}`. That would require changing the `From<&'a str>` impls to `From<&'static str>`, which is doable, but I'm not yet sure if it's worthwhile.
2023-03-28Add `(..)` syntax for RTNMichael Goulet-2/+6
2023-03-05migrate `rustc_hir_analysis` to session diagnosticObei Sideg-27/+23
part two files list: rustc_hir_analysis/variance/* rustc_hir_analysis/missing_cast_for_variadic_arg.rs rustc_hir_analysis/sized_unsized_cast.rs
2023-02-23diagnostics: remove inconsistent English article "this" from E0107Michael Howell-1/+1
Consider `tests/ui/const-generics/generic_const_exprs/issue-102768.stderr`, the error message where it gives additional notes about where the associated type is defined, and how the dead code lint doesn't have an article, like in `tests/ui/lint/dead-code/issue-85255.stderr`. They don't have articles, so it seems unnecessary to have one here.
2023-02-23Auto merge of #108324 - notriddle:notriddle/assoc-fn-method, ↵bors-2/+2
r=compiler-errors,davidtwco,estebank,oli-obk diagnostics: if AssocFn has self argument, describe as method Discussed in https://rust-lang.zulipchat.com/#narrow/stream/147480-t-compiler.2Fwg-diagnostics/topic/.22associated.20function.22.20vs.20.22method.22/near/329265515 This commit also changes the tooltips on rustdoc intra-doc links targeting methods. For anyone not sure why this is being done, see the Reference definitions of these terms in <https://doc.rust-lang.org/1.67.1/reference/items/associated-items.html#methods> > Associated functions whose first parameter is named `self` are called methods and may be invoked using the [method call operator](https://doc.rust-lang.org/1.67.1/reference/expressions/method-call-expr.html), for example, `x.foo()`, as well as the usual function call notation. In particular, while this means it's technically correct for rustc to refer to a method as an associated function (and there are a few cases where it'll still do so), rustc *must never* use the term "method" to refer to an associated function that does not have a `self` parameter.
2023-02-22Remove type-traversal trait aliasesAlan Egerton-2/+2
2023-02-22diagnostics: if AssocFn has self argument, describe as methodMichael Howell-2/+2
Discussed in https://rust-lang.zulipchat.com/#narrow/stream/147480-t-compiler.2Fwg-diagnostics/topic/.22associated.20function.22.20vs.20.22method.22/near/329265515 This commit also changes the tooltips on rustdoc intra-doc links targeting methods.
2023-02-15Copy `ty::AssocItem` all other the placeMaybe Waffle-1/+1
2023-01-17`rustc_hir_analysis`: remove `ref` patternsMaybe Waffle-2/+2
2023-01-06use smaller spans for missing lifetime/generic argsTakayuki Maeda-6/+14
fix rustdoc ui test
2023-01-04rename find_parent_node to opt_parent_idMichael Goulet-1/+1
2022-11-24Change how suggested lifetime args are computed.Camille GILLOT-20/+48
2022-11-19Fix substraction with overflow in `wrong_number_of_generic_args.rs`Mahmoud Mazouz-1/+2
Rarranging the substration and equality check into an addition and an equality check is sufficient. Algebra is cool, isn't it? Co-authored-by: Michael Goulet <michael@errs.io>
2022-09-27rustc_typeck to rustc_hir_analysislcnr-0/+1146