Implement a simple diagnostic system for tidy

[Kobzol]

In #146316 and #146580, contributors independently wanted to reduce the verbose output of tidy. But before, the output was quite ad-hoc, so it was not easy to control it.

In this PR, I implemented a simple diagnostic system for tidy, which allows us to:

1. Only print certain information in verbose mode (-v)
2. Associate each (error) output to a specific check, so that it is easier to find out what exactly has failed and which check you might want to examine (not fully done, there are some random printlns left, but most output should be scoped to a specific check)
3. Print output with colors, based on the message level (message, warning, error)
4. Show the start/end execution of each check in verbose mode, for better progress indication

Failure output:

Success output:

Verbose output (shortened):

CC @nnethercote @RalfJung @GuillaumeGomez

The first two commits and the last commit are interesting, the rest is just mechanical port of the code from bad: &mut bool to DiagCtx and RunningCheck.

The extra_checks check could be further split, but I'd leave that for another PR.

r? @jieyouxu

[rustbot]

The list of allowed third-party dependencies may have been modified! You must ensure that any new dependencies have compatible licenses before merging.

cc @davidtwco, @wesleywiser

tidy extra checks were modified.

cc @lolbinarycat

[lolbinarycat]

in theory, this kinda adds to a general concern i have: i think --verbose is too course of a flag that controls too much. There's a bunch of useful stuff hidden behind it, but there's also a bunch of stuff that is incredibly noisy and not that useful.

however, i think this specific case is probably fine, at least conceptually.

[Kobzol]

Yeah, I agree with that (although that's orthogonal to this PR). We already have a system for passing -v, -vv, etc. to bootstrap, I plan to make a PR to reduce the default verbose output and hide it behind -vv and other more verbose levels.

[Kobzol]

(the verbosity reduction was implemented in #146609)

[lolbinarycat]

(I think the verbosity could still be tweaked a bit, like with all the git commands fetching info, but that's still orthogonal to this PR)

[jieyouxu]

Thanks, changes look good to me. Very glad to see some more systematic treatment of tidy's diagnostics logic.

Can you please squash the commits (since some of them are intermediary and some don't quite correspond to the commit messages as-is)?

You can r=me after.

View changes since this review

[jieyouxu]

@rustbot author

[rustbot]

This PR was rebased onto a different master commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[Kobzol]

@bors r=jieyouxu

[bors]

📌 Commit 4c208f5 has been approved by jieyouxu

It is now in the queue for this repository.

[bors]

⌛ Testing commit 4c208f5 with merge 6710835...

[bors]

☀️ Test successful - checks-actions
Approved by: jieyouxu
Pushing 6710835 to master...

[github-actions]

What is this?

This is an experimental post-merge analysis report that shows differences in test outcomes between the merged PR and its parent PR.

Comparing 1d23da6 (parent) -> 6710835 (this PR)

Test differences

Show 4 test diffs

4 doctest diffs were found. These are ignored, as they are noisy.

Test dashboard

Run

cargo run --manifest-path src/ci/citool/Cargo.toml -- \
    test-dashboard 6710835ae739ca326441ff6c63d24fb123858300 --output-dir test-dashboard

And then open test-dashboard/index.html in your browser to see an overview of all executed tests.

Job duration changes

1. dist-x86_64-apple: 9325.3s -> 6636.1s (-28.8%)
2. dist-apple-various: 4388.7s -> 3496.8s (-20.3%)
3. dist-aarch64-apple: 5888.8s -> 6730.9s (14.3%)
4. aarch64-apple: 5140.5s -> 5586.2s (8.7%)
5. x86_64-gnu-nopt: 7207.4s -> 7768.2s (7.8%)
6. dist-i686-mingw: 9314.1s -> 10003.3s (7.4%)
7. aarch64-gnu-llvm-20-1: 3241.0s -> 3475.3s (7.2%)
8. i686-gnu-nopt-1: 7142.3s -> 7636.1s (6.9%)
9. aarch64-msvc-2: 4833.3s -> 5135.6s (6.3%)
10. dist-android: 1485.7s -> 1575.6s (6.1%)

How to interpret the job duration changes?

Job durations can vary a lot, based on the actual runner instance
that executed the job, system noise, invalidated caches, etc. The table above is provided
mostly for t-infra members, for simpler debugging of potential CI slow-downs.

[rust-timer]

Finished benchmarking commit (6710835): 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 (primary -8.0%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

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

Cycles

Results (primary 5.0%, secondary -2.5%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

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

Binary size

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

Bootstrap: 470.725s -> 470.892s (0.04%)
Artifact size: 387.92 MiB -> 387.92 MiB (-0.00%)