-
Notifications
You must be signed in to change notification settings - Fork 12.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rework how diagnostic lints are stored. #119922
Conversation
cc @davidtwco, @compiler-errors, @TaKO8Ki Some changes occurred to MIR optimizations cc @rust-lang/wg-mir-opt Some changes occurred in need_type_info.rs cc @lcnr |
04c9d37
to
6748d95
Compare
`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.
6748d95
to
d71f535
Compare
FWIW, there are only three
That's few enough that I'm wondering if they're necessary and/or legitimate. |
@@ -104,7 +104,7 @@ pub struct Diagnostic { | |||
pub(crate) level: Level, | |||
|
|||
pub messages: Vec<(DiagnosticMessage, Style)>, | |||
pub code: Option<DiagnosticId>, | |||
pub code: Option<String>, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a way to store an integer instead of a string here? An ErrorCode
type?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes! You're going to love #119972, which I just finished :)
@@ -1382,7 +1382,7 @@ fn compare_number_of_generics<'tcx>( | |||
kind = kind, | |||
), | |||
); | |||
err.code(DiagnosticId::Error("E0049".into())); | |||
err.code("E0049".into()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Drive-by: this should use the error_code!
macro.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I fixed that in #119972.
}, | ||
pub struct IsLint { | ||
/// The lint name. | ||
pub(crate) name: String, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can this use the &Lint
? Or is there an issue with crate dependency order?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Interesting idea. Crate dependencies shouldn't be a problem. This struct has two fields:
name
, which is equivalent toLint::lower_name()
.has_future_breakage
, which is a combination ofLint::future_incompatible
,Lint::default_level
, andsess.opts.unstable_opts.future_incompat_test
. Adding asess
argument toDiagnostic::has_future_breakage()
is awkward.
So I think keeping IsLint
is probably best.
@bors r+ |
… r=oli-obk Rework how diagnostic lints are stored. `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. r? `@oli-obk`
…iaskrgr Rollup of 6 pull requests Successful merges: - rust-lang#119062 (Deny braced macro invocations in let-else) - rust-lang#119922 (Rework how diagnostic lints are stored.) - rust-lang#119978 (Move async closure parameters into the resultant closure's future eagerly) - rust-lang#119984 (Change return type of unstable `Waker::noop()` from `Waker` to `&Waker`.) - rust-lang#120020 (Gracefully handle missing typeck information if typeck errored) - rust-lang#120021 (don't store const var origins for known vars) r? `@ghost` `@rustbot` modify labels: rollup
… r=oli-obk Rework how diagnostic lints are stored. `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. r? ``@oli-obk``
…iaskrgr Rollup of 7 pull requests Successful merges: - rust-lang#119855 (Enable Static Builds for FreeBSD) - rust-lang#119922 (Rework how diagnostic lints are stored.) - rust-lang#119978 (Move async closure parameters into the resultant closure's future eagerly) - rust-lang#119984 (Change return type of unstable `Waker::noop()` from `Waker` to `&Waker`.) - rust-lang#120020 (Gracefully handle missing typeck information if typeck errored) - rust-lang#120021 (don't store const var origins for known vars) - rust-lang#120032 (Fix `rustc_abi` build on stable) r? `@ghost` `@rustbot` modify labels: rollup
…iaskrgr Rollup of 7 pull requests Successful merges: - rust-lang#119855 (Enable Static Builds for FreeBSD) - rust-lang#119922 (Rework how diagnostic lints are stored.) - rust-lang#119978 (Move async closure parameters into the resultant closure's future eagerly) - rust-lang#119984 (Change return type of unstable `Waker::noop()` from `Waker` to `&Waker`.) - rust-lang#120020 (Gracefully handle missing typeck information if typeck errored) - rust-lang#120021 (don't store const var origins for known vars) - rust-lang#120032 (Fix `rustc_abi` build on stable) r? `@ghost` `@rustbot` modify labels: rollup
☀️ Test successful - checks-actions |
Finished benchmarking commit (16f4b02): comparison URL. Overall result: no relevant changes - no action needed@rustbot label: -perf-regression Instruction countThis benchmark run did not return any relevant results for this metric. Max RSS (memory usage)ResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 665.423s -> 666.76s (0.20%) |
Diagnostic::code
has the typeDiagnosticId
, which hasError
andLint
variants. PlusDiagnostic::is_lint
is a bool, which should beredundant 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 asError
, andis_lint
isrequired to indicate that it's a lint. This is what happens with
derive(LintDiagnostic)
lints. Which means those lints don't have alint name or a
has_future_breakage
field because those are stored inthe
DiagnosticId::Lint
.It's all a bit messy and confused and seems unintentional.
This commit:
DiagnosticId
;Diagnostic::code
toOption<String>
, which means botherrors and lints can straightforwardly have an error code;
Diagnostic::is_lint
toOption<IsLint>
, whereIsLint
is anew type containing a lint name and a
has_future_breakage
bool, soall lints can have those, error code or not.
r? @oli-obk