about summary refs log tree commit diff
path: root/compiler/rustc_middle/src/lint.rs
AgeCommit message (Collapse)AuthorLines
2024-03-17Guard decorate on when not to skip instead许杰友 Jieyou Xu (Joe)-7/+4
2024-03-17Invoke decorate when error level is beyond warning, including error许杰友 Jieyou Xu (Joe)-7/+16
2024-03-17Only invoke `decorate` if the diag can eventually be emitted许杰友 Jieyou Xu (Joe)-2/+10
2024-03-05Rename `DiagnosticMessage` as `DiagMessage`.Nicholas Nethercote-3/+3
2024-02-28Rename `DiagnosticBuilder` as `Diag`.Nicholas Nethercote-8/+7
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-4/+4
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-13Do not point at `#[allow(_)]` as the reason for compat lint triggeringEsteban Küber-0/+5
Fix #121009.
2024-01-23Rename `struct_lint_level` as `lint_level`.Nicholas Nethercote-3/+3
2024-01-23Rename `TyCtxt::emit_spanned_lint` as `TyCtxt::emit_node_span_lint`.Nicholas Nethercote-1/+1
2024-01-23Rename `TyCtxt::emit_lint` as `TyCtxt::emit_node_lint`.Nicholas Nethercote-1/+1
2024-01-23Rename `TyCtxt::struct_span_lint_hir` as `TyCtxt::node_span_lint`.Nicholas Nethercote-1/+1
2024-01-23Rename `TyCtxt::struct_lint_node` as `TyCtxt::node_lint`.Nicholas Nethercote-1/+1
2024-01-23Rename `LintContext::lookup` as `LintContext::opt_span_lint`.Nicholas Nethercote-1/+1
2024-01-14Rework how diagnostic lints are stored.Nicholas Nethercote-5/+2
`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-11Change how `force-warn` lint diagnostics are recorded.Nicholas Nethercote-8/+6
`is_force_warn` is only possible for diagnostics with `Level::Warning`, but it is currently stored in `Diagnostic::code`, which every diagnostic has. This commit: - removes the boolean `DiagnosticId::Lint::is_force_warn` field; - adds a `ForceWarning` variant to `Level`. Benefits: - The common `Level::Warning` case now has no arguments, replacing lots of `Warning(None)` occurrences. - `rustc_session::lint::Level` and `rustc_errors::Level` are more similar, both having `ForceWarning` and `Warning`.
2024-01-08Use chaining for `DiagnosticBuilder` construction and `emit`.Nicholas Nethercote-1/+0
To avoid the use of a mutable local variable, and because it reads more nicely.
2024-01-04Remove `is_lint` field from `Level::Error`.Nicholas Nethercote-1/+1
Because it's redundant w.r.t. `Diagnostic::is_lint`, which is present for every diagnostic level. `struct_lint_level_impl` was the only place that set the `Error` field to `true`, and it's also the only place that calls `Diagnostic::is_lint()` to set the `is_lint` field.
2024-01-03Rename some `Diagnostic` setters.Nicholas Nethercote-3/+3
`Diagnostic` has 40 methods that return `&mut Self` and could be considered setters. Four of them have a `set_` prefix. This doesn't seem necessary for a type that implements the builder pattern. This commit removes the `set_` prefixes on those four methods.
2023-12-31rustc_lint: Make `LintLevelsProvider::current_specs()` return `&FxIndexMap`Martin Nordholts-2/+2
So that lint iteration order becomes predicitable. Discovered with `rustc::potential_query_instability`.
2023-12-23Streamline `struct_lint_level`.Nicholas Nethercote-23/+13
We can just get the error level in the `match` and then use `DiagnosticBuilder::new`. This then means a number of `DiagCtxt` functions are no longer needed, because this was the one place that used them. Note: the commit changes the treatment of spans for `Expect`, which was different to all the other cases, but this has no apparent effect.
2023-12-18Rename `Session::span_diagnostic` as `Session::dcx`.Nicholas Nethercote-2/+2
2023-12-18Rename `HandlerInner` as `DiagCtxtInner`.Nicholas Nethercote-1/+1
2023-12-15Fix commentsMichael Goulet-22/+3
2023-12-15Don't pass lint back out of lint decoratorMichael Goulet-9/+2
2023-11-04Remove support for compiler plugins.Nicholas Nethercote-2/+1
They've been deprecated for four years. This commit includes the following changes. - It eliminates the `rustc_plugin_impl` crate. - It changes the language used for lints in `compiler/rustc_driver_impl/src/lib.rs` and `compiler/rustc_lint/src/context.rs`. External lints are now called "loaded" lints, rather than "plugins" to avoid confusion with the old plugins. This only has a tiny effect on the output of `-W help`. - E0457 and E0498 are no longer used. - E0463 is narrowed, now only relating to unfound crates, not plugins. - The `plugin` feature was moved from "active" to "removed". - It removes the entire plugins chapter from the unstable book. - It removes quite a few tests, mostly all of those in `tests/ui-fulldeps/plugin/`. Closes #29597.
2023-11-02Minimize `pub` usage in `source_map.rs`.Nicholas Nethercote-3/+2
Most notably, this commit changes the `pub use crate::*;` in that file to `use crate::*;`. This requires a lot of `use` items in other crates to be adjusted, because everything defined within `rustc_span::*` was also available via `rustc_span::source_map::*`, which is bizarre. The commit also removes `SourceMap::span_to_relative_line_string`, which is unused.
2023-09-22give FutureIncompatibilityReason variants more explicit namesRalf Jung-3/+6
2023-09-04Add help to allow lint for the implied by suggestionUrgau-0/+3
2023-08-02fix RedundantLocals clippy caused by async and awaityukang-0/+9
2023-08-02Fix #107113, avoid suggest for macro attributesyukang-1/+5
2023-07-30inline format!() args up to and including rustc_middleMatthias Krüger-9/+5
2023-07-18Add `#[track_caller]` to lint related diagnostic functionsMaybe Waffle-0/+2
2023-07-12Move `maybe_lint_level_root_bounded`.Nicholas Nethercote-20/+0
From `TyCtxt` to the MIR `Builder`. This will allow us to add a cache to `Builder` and use it from `maybe_lint_level_root_bounded`.
2023-06-27Simplify some conditionsMaybe Waffle-3/+4
2023-05-29Use `Cow` in `{D,Subd}iagnosticMessage`.Nicholas Nethercote-1/+1
Each of `{D,Subd}iagnosticMessage::{Str,Eager}` has a comment: ``` // FIXME(davidtwco): can a `Cow<'static, str>` be used here? ``` This commit answers that question in the affirmative. It's not the most compelling change ever, but it might be worth merging. This requires changing the `impl<'a> From<&'a str>` impls to `impl From<&'static str>`, which involves a bunch of knock-on changes that require/result in call sites being a little more precise about exactly what kind of string they use to create errors, and not just `&str`. This will result in fewer unnecessary allocations, though this will not have any notable perf effects given that these are error paths. Note that I was lazy within Clippy, using `to_string` in a few places to preserve the existing string imprecision. I could have used `impl Into<{D,Subd}iagnosticMessage>` in various places as is done in the compiler, but that would have required changes to *many* call sites (mostly changing `&format("...")` to `format!("...")`) which didn't seem worthwhile.
2023-05-25Remove ExpnKind::Inlined.Camille GILLOT-2/+1
2023-05-03Restrict `From<S>` for `{D,Subd}iagnosticMessage`.Nicholas Nethercote-6/+6
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-01-10create helper function for `rustc_lint_defs::Level` and remove it's ↵ozkanonur-10/+1
duplicated code r=ozkanonur Signed-off-by: ozkanonur <work@onurozkan.dev>
2023-01-04rename get_parent_node to parent_idMichael Goulet-1/+1
2022-11-06fix: typoRejyr-1/+1
2022-10-16fix typoRalf Jung-1/+1
2022-10-12Apply suggestions from code reviewWaffle Maybe-9/+4
Co-authored-by: Ralf Jung <post@ralfj.de>
2022-10-12Improve docs for `struct_lint_level` function.Maybe Waffle-0/+38
2022-10-04Rollup merge of #102568 - compiler-errors:lint-unsatisfied-opaques, r=oli-obkDylan DPC-1/+3
Lint against nested opaque types that don't satisfy associated type bounds See the test failures for examples of places where this lint would fire. r? `@oli-obk`
2022-10-04Rollup merge of #102567 - compiler-errors:issue-102561, r=davidtwcoMatthias Krüger-1/+4
Delay evaluating lint primary message until after it would be suppressed Fixes #102561 Fixes #102572
2022-10-02Lint for unsatisfied nested opaquesMichael Goulet-1/+3
2022-10-02Remove a couple lifetimes that could be inferedMaybe Waffle-7/+6
2022-10-02Delay evaluating lint primary message until after it would be suppressedMichael Goulet-1/+4
2022-10-01Use a SortedMap instead of a VecMap.Camille GILLOT-2/+2
2022-10-01Compute by owner instead of HirId.Camille GILLOT-6/+19