Streamline rustc_span::HashStableContext.

[nnethercote]

Currently this trait has five methods. But it only really needs three.

For example, currently stable hashing of spans is implemented in rustc_span, except a couple of sub-operations are delegated to rustc_query_system: def_span and span_data_to_lines_and_cols. These two delegated sub-operations can be reduced to a single delegated operation that does the full hash computation.

Likewise, assert_default_hashing_controls depends on two delegated sub-operations, hashing_controls and
unstable_opts_incremental_ignore_spans, and can be simplified.

I find the resulting code simpler and clearer -- when necessary, we do a whole operation in rustc_query_system instead of doing it partly in rustc_span and partly in rustc_query_system.

r? @cjgillot

[nnethercote]

@bors try @rust-timer queue

[rust-bors]

☀️ Try build successful (CI)
Build commit: 8d7aeb5 (8d7aeb56614e814d931ebd8e119d10e0a1fa829b, parent: 08a4ce529f4ea17ad1c0fa2e39ca1f5e7cd047b6)

[rust-timer]

Finished benchmarking commit (8d7aeb5): comparison URL.

Overall result: ❌ regressions - please read the text below

Benchmarking this pull request means it may be perf-sensitive – we'll automatically label it not fit for rolling up. You can override this, but we strongly advise not to, due to possible changes in compiler perf.

Next Steps: If you can justify the regressions found in this try perf run, please do so in sufficient writing along with @rustbot label: +perf-regression-triaged. If not, please fix the regressions and do another perf run. If its results are neutral or positive, the label will be automatically removed.

@bors rollup=never
@rustbot label: -S-waiting-on-perf +perf-regression

Instruction count

Our most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.

	mean	range	count
Regressions ❌ (primary)	0.3%	[0.1%, 0.6%]	19
Regressions ❌ (secondary)	0.4%	[0.2%, 0.9%]	23
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.3%	[0.1%, 0.6%]	19

Max RSS (memory usage)

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

Cycles

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

Binary size

Results (primary -0.0%, secondary -0.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)	-0.0%	[-0.0%, -0.0%]	7
Improvements ✅ (secondary)	-0.0%	[-0.1%, -0.0%]	13
All ❌✅ (primary)	-0.0%	[-0.0%, -0.0%]	7

Bootstrap: 476.152s -> 476.94s (0.17%)
Artifact size: 397.96 MiB -> 397.74 MiB (-0.06%)

[nnethercote]

This is the part of #152086 that I pulled out because of performance regressions. Locally I don't see regressions, I see very small improvements, which suggests it's a minor thing like an inlining choice. Also, this PR affects incremental hashing, so rustc-perf's enabling of -Zincremental-verify-ich will exaggerate the effect here. Hmm.

[nnethercote]

Let's try a slightly different #[inline] configuration.

@bors try @rust-timer queue

[rust-bors]

☀️ Try build successful (CI)
Build commit: 1381776 (13817764ad7295dd204201bd10cf80158358ac33, parent: 13c38730d981289cc7ae4cc109fd7756bf83ee67)

[rust-timer]

Finished benchmarking commit (1381776): comparison URL.

Overall result: no relevant changes - no action needed

Benchmarking this pull request means it may be perf-sensitive – we'll automatically label it not fit for rolling up. You can override this, but we strongly advise not to, due to possible changes in compiler perf.

@bors rollup=never
@rustbot label: -S-waiting-on-perf -perf-regression

Instruction count

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

Max RSS (memory usage)

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

Cycles

Results (secondary -0.7%)

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)	2.1%	[2.1%, 2.1%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-3.5%	[-3.5%, -3.5%]	1
All ❌✅ (primary)	-	-	0

Binary size

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

Bootstrap: 471.737s -> 475.18s (0.73%)
Artifact size: 397.92 MiB -> 397.93 MiB (0.00%)

[nnethercote]

This is the part of #152086 that I pulled out because of performance regressions. Locally I don't see regressions, I see very small improvements, which suggests it's a minor thing like an inlining choice. Also, this PR affects incremental hashing, so rustc-perf's enabling of -Zincremental-verify-ich will exaggerate the effect here. Hmm.

The inlining tweak fixed the perf regression, and @cjgillot already approved this commit in #152086, so this is ready to merge.

@bors r=cjgillot

[rust-bors]

📌 Commit 0f31083 has been approved by cjgillot

It is now in the queue for this repository.

[rust-bors]

☀️ Test successful - CI
Approved by: cjgillot
Duration: 3h 27m 50s
Pushing 39219ce to main...

[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 1c316d3 (parent) -> 39219ce (this PR)

Test differences

Show 18 test diffs

18 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 39219ceb97d1b37dda72517daa9ebe8364ffe186 --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. pr-check-1: 27m 27s -> 32m 57s (+20.0%)
2. i686-gnu-2: 1h 28m -> 1h 43m (+16.7%)
3. x86_64-gnu-gcc: 59m 17s -> 1h 8m (+16.3%)
4. x86_64-gnu-miri: 1h 13m -> 1h 24m (+15.6%)
5. aarch64-gnu-debug: 1h 6m -> 1h 16m (+14.9%)
6. x86_64-gnu: 2h 7m -> 2h 23m (+12.0%)
7. x86_64-gnu-llvm-20: 1h 11m -> 1h 19m (+11.3%)
8. x86_64-gnu-llvm-21-2: 1h 31m -> 1h 41m (+10.8%)
9. aarch64-msvc-2: 1h 41m -> 1h 53m (+10.8%)
10. x86_64-gnu-stable: 2h 11m -> 2h 25m (+10.5%)

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 (39219ce): 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 -4.3%, secondary -5.3%)

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)	-4.3%	[-4.3%, -4.3%]	1
Improvements ✅ (secondary)	-5.3%	[-5.3%, -5.3%]	1
All ❌✅ (primary)	-4.3%	[-4.3%, -4.3%]	1

Cycles

Results (secondary 3.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)	3.0%	[3.0%, 3.0%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-	-	0

Binary size

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

Bootstrap: 475.432s -> 477.309s (0.39%)
Artifact size: 397.82 MiB -> 397.86 MiB (0.01%)