Rework how diagnostic lints are stored. #119922

nnethercote · 2024-01-13T11:32:14Z

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

rustbot · 2024-01-13T11:32:22Z

rustc_macros::diagnostics was changed

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

`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.

nnethercote · 2024-01-14T09:23:06Z

FWIW, there are only three derive(LintDiagnostic) diagnostics with a code:

UnknownLintFromCommandLine (E0602)
BindingsWithVariantName (E0170)
ReprConflictingLint (E0566)

That's few enough that I'm wondering if they're necessary and/or legitimate.

cjgillot · 2024-01-14T17:34:40Z

compiler/rustc_errors/src/diagnostic.rs

@@ -104,7 +104,7 @@ pub struct Diagnostic {
    pub(crate) level: Level,

    pub messages: Vec<(DiagnosticMessage, Style)>,
-    pub code: Option<DiagnosticId>,
+    pub code: Option<String>,


Is there a way to store an integer instead of a string here? An ErrorCode type?

Yes! You're going to love #119972, which I just finished :)

cjgillot · 2024-01-14T17:35:26Z

compiler/rustc_hir_analysis/src/check/compare_impl_item.rs

@@ -1382,7 +1382,7 @@ fn compare_number_of_generics<'tcx>(
                    kind = kind,
                ),
            );
-            err.code(DiagnosticId::Error("E0049".into()));
+            err.code("E0049".into());


Drive-by: this should use the error_code! macro.

I fixed that in #119972.

cjgillot · 2024-01-14T17:46:52Z

compiler/rustc_errors/src/diagnostic.rs

-    },
+pub struct IsLint {
+    /// The lint name.
+    pub(crate) name: String,


Can this use the &Lint? Or is there an issue with crate dependency order?

Interesting idea. Crate dependencies shouldn't be a problem. This struct has two fields:

name, which is equivalent to Lint::lower_name().

has_future_breakage, which is a combination of Lint::future_incompatible, Lint::default_level, and sess.opts.unstable_opts.future_incompat_test. Adding a sess argument to Diagnostic::has_future_breakage() is awkward.

So I think keeping IsLint is probably best.

oli-obk · 2024-01-16T09:59:58Z

@bors r+

bors · 2024-01-16T10:00:01Z

📌 Commit d71f535 has been approved by oli-obk

It is now in the queue for this repository.

… 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

bors · 2024-01-17T07:33:55Z

⌛ Testing commit d71f535 with merge 16f4b02...

bors · 2024-01-17T09:30:56Z

☀️ Test successful - checks-actions
Approved by: oli-obk
Pushing 16f4b02 to master...

rust-timer · 2024-01-17T10:42:16Z

Finished benchmarking commit (16f4b02): comparison URL.

Overall result: no relevant changes - no action needed

@rustbot label: -perf-regression

Instruction count

This benchmark run did not return any relevant results for this metric.

Max RSS (memory usage)

Results

This 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.

	mean	range	count
Regressions ❌ (primary)	2.7%	[2.7%, 2.7%]	1
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-5.0%	[-5.0%, -5.0%]	1
All ❌✅ (primary)	2.7%	[2.7%, 2.7%]	1

Cycles

Results

This 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.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	2.0%	[2.0%, 2.0%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-2.8%	[-3.6%, -2.1%]	7
All ❌✅ (primary)	-	-	0

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 665.423s -> 666.76s (0.20%)
Artifact size: 308.34 MiB -> 308.34 MiB (0.00%)

rustbot assigned oli-obk Jan 13, 2024

Reformat struct_span_code_err!.

2de99ec

nnethercote force-pushed the fix-Diag-code-is_lint branch 3 times, most recently from 04c9d37 to 6748d95 Compare January 14, 2024 02:55

nnethercote force-pushed the fix-Diag-code-is_lint branch from 6748d95 to d71f535 Compare January 14, 2024 03:04

cjgillot reviewed Jan 14, 2024

View reviewed changes

nnethercote mentioned this pull request Jan 14, 2024

Add ErrCode #119972

Merged

bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jan 16, 2024

matthiaskrgr mentioned this pull request Jan 16, 2024

Rollup of 6 pull requests #120030

Closed

matthiaskrgr mentioned this pull request Jan 16, 2024

Rollup of 7 pull requests #120034

Closed

bors added the merged-by-bors This PR was explicitly merged by bors. label Jan 17, 2024

bors merged commit 16f4b02 into rust-lang:master Jan 17, 2024

rustbot added this to the 1.77.0 milestone Jan 17, 2024

nnethercote deleted the fix-Diag-code-is_lint branch January 21, 2024 20:58

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Rework how diagnostic lints are stored. #119922

Rework how diagnostic lints are stored. #119922

Uh oh!

nnethercote commented Jan 13, 2024 •

edited

Loading

Uh oh!

rustbot commented Jan 13, 2024

Uh oh!

nnethercote commented Jan 14, 2024

Uh oh!

cjgillot Jan 14, 2024

Uh oh!

nnethercote Jan 14, 2024

Uh oh!

cjgillot Jan 14, 2024

Uh oh!

nnethercote Jan 14, 2024

Uh oh!

cjgillot Jan 14, 2024

Uh oh!

nnethercote Jan 14, 2024

Uh oh!

oli-obk commented Jan 16, 2024

Uh oh!

bors commented Jan 16, 2024

Uh oh!

bors commented Jan 17, 2024

Uh oh!

bors commented Jan 17, 2024

Uh oh!

rust-timer commented Jan 17, 2024

Uh oh!

Uh oh!

Rework how diagnostic lints are stored. #119922

Rework how diagnostic lints are stored. #119922

Uh oh!

Conversation

nnethercote commented Jan 13, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rustbot commented Jan 13, 2024

Uh oh!

nnethercote commented Jan 14, 2024

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

oli-obk commented Jan 16, 2024

Uh oh!

bors commented Jan 16, 2024

Uh oh!

bors commented Jan 17, 2024

Uh oh!

bors commented Jan 17, 2024

Uh oh!

rust-timer commented Jan 17, 2024

Overall result: no relevant changes - no action needed

Uh oh!

Uh oh!

nnethercote commented Jan 13, 2024 •

edited

Loading