[dianne]

rather than doing a separate traversal each time we encounter a point we can lifetime-extend through (i.e. a let statement initializer or a const/static body), this tracks the scope lifetime-extended temporaries should be extended to in a similar way to how it tracks whether subexpressions introduce temporary scopes.

this refactor is the basis for both #146098 and #160297 (the latter of which is part of rust-lang/goals#648), as it makes the things I'm doing there easier to implement. the additional tests are also pulled from #146098, since I expect we want to have them around regardless of that PR being blocked

[dianne]

@bors try @rust-timer queue

[rust-bors]

☀️ Try build successful (CI)
Build commit: a18535c (a18535c32cc670e9affe18831a3eb1157e872cc3)
Base parent: 92b5b8c (92b5b8c87c61b20adc9001b41baf587634a74734)

[rust-timer]

Finished benchmarking commit (a18535c): comparison URL.

Overall result: ❌✅ regressions and improvements - please read:

Benchmarking means the PR may be perf-sensitive. Consider adding rollup=never if this change is not fit for rolling up.

Next, please: If you can, justify the regressions found in this try perf run in writing along with @rustbot label: +perf-regression-triaged. If not, fix the regressions and do another perf run. Neutral or positive results will clear the label automatically.

@bors rollup=iffy rustc-perf
@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.2%	[0.2%, 0.2%]	4
Improvements ✅ (primary)	-0.2%	[-0.2%, -0.1%]	5
Improvements ✅ (secondary)	-0.2%	[-0.2%, -0.2%]	2
All ❌✅ (primary)	-0.2%	[-0.2%, -0.1%]	5

Max RSS (memory usage)

Results (primary 2.3%, secondary 1.7%)

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

	mean	range	count
Regressions ❌ (primary)	2.3%	[2.3%, 2.3%]	1
Regressions ❌ (secondary)	2.6%	[2.3%, 2.8%]	3
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-1.0%	[-1.0%, -1.0%]	1
All ❌✅ (primary)	2.3%	[2.3%, 2.3%]	1

Cycles

Results (primary 2.8%)

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

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

Binary size

This perf run didn't have relevant results for this metric.

Bootstrap: 484.843s -> 488.027s (0.66%)
Artifact size: 406.61 MiB -> 406.78 MiB (0.04%)

[tiif]

r? me I will at least do a first pass review on this.

[dianne]

the tt-muncher perf regressions seem like they're likely noise, or at least not directly related to what this PR is doing? locally profiling the one with the highest significance factor (check, incr-unchanged), ~97% of the icount diff looks to be in <rustc_expand::expand::MacroExpander>::fully_expand_fragment, which of course happens before temporary scoping (and is about where I'd expect the most icount variance, considering the benchmark)

maybe it'd be worth doing another try build and perf run sometime to see if it stops reporting regressions? I'll leave things as-is for now though