resolve: In visit_scopes do not extract ctxt out of span unless necessary

[petrochenkov]

This recovers the second half of perf regressions from #149681 (the first part was recovered in #150741).

[rustbot]

r? @JonathanBrouwer

rustbot has assigned @JonathanBrouwer.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[petrochenkov]

@bors try @rust-timer queue

[rust-bors]

☀️ Try build successful (CI)
Build commit: 90c065e (90c065e1f1941f1648bc62a8e863ed65d412035b, parent: b68e16cfc0e9f8b29c9ec41bfa6ab0a637eff19c)

[rust-timer]

Finished benchmarking commit (90c065e): comparison URL.

Overall result: ✅ improvements - 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

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

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	0.7%	[0.7%, 0.7%]	1
Improvements ✅ (primary)	-0.3%	[-0.5%, -0.1%]	95
Improvements ✅ (secondary)	-0.3%	[-0.8%, -0.1%]	48
All ❌✅ (primary)	-0.3%	[-0.5%, -0.1%]	95

Max RSS (memory usage)

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

Cycles

Results (secondary 3.2%)

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.2%	[3.2%, 3.2%]	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: 473.667s -> 471.559s (-0.45%)
Artifact size: 391.39 MiB -> 391.39 MiB (0.00%)

[petrochenkov]

The benefits here are actually larger than I expected.

This is good, but if we want to apply the same approach to working with SyntaxContexts consistently, then the implications for developer experience are a bit annoying.

The optimal way of modifying syntax contexts is:

• If we do not modify it, then do not extract it from Span.
• If we modify it more than once, then extract it from Span, modify, and then re-package into Span again in the end.
• If we modify it once, then do not extract it from Span, but rather do an in-place update (but extracting, modifying and repackaging, like in the previous item, is probably not much worse).

Of course we don't know which scenario applies until runtime.
Perhaps we need some wrapper type around Span doing all of the above conveniently...

[rustbot]

This PR was rebased onto a different main 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.

[petrochenkov]

@rustbot ready

[JonathanBrouwer]

@bors r+ rollup=never

[rust-bors]

📌 Commit 0361bd0 has been approved by JonathanBrouwer

It is now in the queue for this repository.