Temporary lifetime extension for blocks #146098

dianne · 2025-09-01T17:32:34Z

This implements a revised version of the temporary lifetime extension semantics I suggested in #145838 (comment), with the goal of making temporary lifetimes and drop order more consistent between extending and non-extending blocks. As a consequence, this undoes the breaking change introduced by #145838 (but in exchange has a much larger surface area).

The change this PR hopes to enforce is a general rule: any expression's temporaries should have the same relative drop order regardless of whether the expression is in an extending context or not: let _ = $expr; and drop($expr); should have the same drop order. To achieve that, this PR applies lifetime extension rules to blocks:

// This `temp()` is now extended past the block tail in all contexts.
{ &temp() }

now extends the lifetime of temp() to outlive the block tail in Rust 2024 regardless of whether the block is an extending expression in a let statement initializer (in which context it was already extended to outlive the block before this PR). The scoping rules for tails of extending blocks remain the same: extending subexpressions' temporary scopes are extended based on the source of the lifetime extension (e.g. to match the scope of a parent let statement's bindings). For blocks not extended by any other source, extending borrows in the tail expression now share a temporary scope with the result of the block. This can in turn extend nested blocks within blocks' tail expressions:

// This `temp()` is extended past the outer block tail.
// It is now dropped after the reference to it at the `;`.
f({{ &temp() }});

// This context-sensitivity is consistent with `let`:
// This `temp()` was already extended.
// It is still dropped after `x` at the end of its scope.
let x = {{ &temp() }};

Since this uses the same rules as let, it only applies to extending sub-expressions.

// This `temp()` is still never extended in any context.
// In Rust 2024, it is dropped at the end of the block tail.
{ identity(&temp()) }

This also applies to if expressions' blocks since lifetime extension applies to if blocks' tail expressions, meaning it affects all editions. This is where breakage from #145838 was observed:

if cond { &temp() } else { &temp() }

now extends temp() to have the same temporary scope as the result of the if expression.

As a further consequence, this makes super let in if expressions' blocks more consistent with block expressions:

if cond() {
    super let x = temp();
    &temp
} else {
    super let x = temp();
    &temp
}

previously only worked in extending contexts (since the super lets would be extended), and now it works everywhere.

I don't think this is ready to merge yet. It should have a Reference PR, it will need a lang FCP, and it may need other things as well.

@rustbot label +T-lang

dianne · 2025-09-01T17:52:35Z

@rustbot label -stable-nominated

I'm not intending to stable-nominate this, at least. Someone else can, but I don't expect it's needed or that it would be accepted.

traviscross · 2025-09-02T04:48:46Z

Does this only affect code in Rust 2024, or would you expect any visible difference in earlier editions?

dianne · 2025-09-02T05:34:34Z

~~It should only be visible in Rust 2024. The only extending expressions that introduce temporary drop scopes are Rust 2024 block tail expressions.~~ Edit: this is also visible on earlier editions through if expressions' blocks.

Suppose we have a macro extending!, for which $expr is extending if extending!($expr) is extending. Under this PR, in a non-extending context, { extending!(&temp()) } would give temp() the same temporary scope as the result of the block. ~~Prior to Rust 2021, they're already in the same scope, due to extending! being unable to introduce temporary scopes.~~

Or to generalize this, the aim of this PR is that in a non-extending context, extending!(&temp()) should give temp() the same temporary scope as the expansion, similar to how let x = extending!(&temp()); gives temp() the same scope as x. ~~This already holds in Rust 2021 and prior.~~

If new expressions are added to Rust that are both extending and temporary scopes, I'd want this behavior to apply to them as well.

traviscross · 2025-09-02T07:55:47Z

Since this would effectively reduce the scope of the Rust 2024 tail expression temporary scope change, we'd also want to be sure to reflect that in the behavior of the tail-expr-drop-order lint.

dianne · 2025-09-02T08:36:58Z

I haven't done extensive testing, but see this test diff for that lint: lint-tail-expr-drop-order-borrowck.rs. I'm applying the lifetime extension rules on all editions, and lifetime extension prevents the temporary scope from being registered as potentially forwards-incompatible (even though the extended scopes are technically the same as the old scopes in old editions). Though I think I've convinced myself at this point that lifetime extension doesn't need to be applied to block tails of non-extending old-edition blocks¹, so potentially the lint change could be implemented in some other way instead.

I was worried about mixed-edition code, but I don't think it's an issue anymore. ↩

bors · 2025-09-17T11:59:52Z

☔ The latest upstream changes (presumably #146666) made this pull request unmergeable. Please resolve the merge conflicts.

Co-authored-by: Travis Cross <[email protected]>

This is the real-world way that the unintentional stabilization of lifetime extension for format arguments was used.

dianne · 2025-09-19T23:50:53Z

I've made some revisions. This should now properly handle if expressions' blocks, meaning it affects all editions (since if blocks are both terminating in all editions and extending when the if expression is extending). Of note, I didn't notice at the time, but I think #145838 affected all editions as well (including the real-world breakage), due to if blocks working like that.

I think the implementation will likely need optimization and cleanup, but it might take a bit of refactoring to get it to a good place, so I'd like to get a vibe check on the design first, if there's room for it in a lang team meeting.

@rustbot label +I-lang-nominated

traviscross · 2025-09-24T16:07:13Z

@bors2 try

Temporary lifetime extension for blocks

rust-bors · 2025-09-24T18:20:42Z

☀️ Try build successful (CI)
Build commit: 028592f (028592fec99e54cc92def5a2a849c673b066dd93, parent: e9385f9eea0221ef295a188d49d16f8f5189abf1)

traviscross · 2025-09-24T18:22:32Z

@craterbot run mode=build-and-test

craterbot · 2025-09-24T18:23:03Z

👌 Experiment pr-146098 created and queued.
🤖 Automatically detected try build 028592f
🔍 You can check out the queue and this experiment's details.

ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

traviscross · 2025-09-24T19:36:46Z

We talked about this in the lang call today. Our vibe was positive toward this. Let's see what crater says.

tgross35 · 2025-09-25T03:15:24Z

Requested on Zulip
@rust-timer queue

Kobzol · 2025-09-25T05:59:53Z

Note that queue waits for a try build to be finished, to benchmark an existing build, the command is rust-timer build=SHA.

I'll redo the try build, as once it's queud, the build command probably won't work anymore.

@bors try

Temporary lifetime extension for blocks

rust-bors · 2025-09-25T08:11:15Z

☀️ Try build successful (CI)
Build commit: 2440211 (2440211fe03bc45c89b6dc1a3df18382ce91e32b, parent: caccb4d0368bd918ef6668af8e13834d07040417)

rust-timer · 2025-09-25T09:20:56Z

Finished benchmarking commit (2440211): 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.5%	[0.5%, 0.6%]	2
Regressions ❌ (secondary)	0.1%	[0.1%, 0.3%]	4
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.5%	[0.5%, 0.6%]	2

Max RSS (memory usage)

Results (primary 7.2%)

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

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

Cycles

Results (secondary -2.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)	-	-	0
Improvements ✅ (secondary)	-2.3%	[-2.7%, -2.1%]	5
All ❌✅ (primary)	-	-	0

Binary size

Results (primary -0.1%, secondary 0.1%)

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

	mean	range	count
Regressions ❌ (primary)	0.1%	[0.1%, 0.1%]	1
Regressions ❌ (secondary)	0.1%	[0.1%, 0.1%]	1
Improvements ✅ (primary)	-0.2%	[-0.2%, -0.0%]	7
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-0.1%	[-0.2%, 0.1%]	8

Bootstrap: 472.505s -> 469.233s (-0.69%)
Artifact size: 387.91 MiB -> 387.87 MiB (-0.01%)

dianne · 2025-09-25T10:26:42Z

Is there a way to tell where instruction count regressions are from? Looking at the wall time breakdown from the detailed report pages though, it looks like this doesn't make region_scope_tree significantly slower. e.g. the regression in cargo-0.87.1 (full) seems to be from spending more time in codegen (including a couple more executions of is_codegened_item) and the extra query executions in cranelift-codegen-0.119.0 (incr-patched: println) also have nothing directly to do with region_scope_tree as far as I can tell. If this PR is affecting their performance, it could be through assigning different scopes to temporaries in already-compiling code; it seems it can shuffle StorageDeads around at least¹. If that's the cause of any of those regressions, it would be a consequence of this change's design (and its interactions with certain implementation details elsewhere in the compiler¹) rather than in inefficiencies in my unoptimized scope resolution implementation.

This came up in a single mir-opt test (diff here). One temporary involved in a slice indexing operation was extended slightly so that its StorageDead swapped with another temporary's. Notably, the slice indexing expression being borrowed from there is a place expression; as I understand at least, its temporaries are implementation details and shouldn't need to live for the temporary scope of the expression (and indeed, the borrowed element outlives the temporary scope of the indexing expression without issue). But it seemingly does use the expression's temporary scope, as it was extended. ↩ ↩²

Kobzol · 2025-09-25T10:44:10Z

Cachegrind can be used to show function-level profiling results using https://github.com/rust-lang/rustc-perf:

cargo run --release --bin collector \
    profile_local cachegrind \
    +caccb4d0368bd918ef6668af8e13834d07040417 \
    --rustc2 +2440211fe03bc45c89b6dc1a3df18382ce91e32b \
    --exact-match cargo-0.87.1 \
    --profiles Opt \
    --scenarios Full

dianne · 2025-09-26T00:35:36Z

Thanks! Looking at the diff for the cargo (full) test, it indeed looks like the instruction count increase for that test is in llvm; the diff was dominated by changes in llvm instruction counts (mostly increases). I couldn't find any functions in rustc_hir_analysis::check::region in there (or things I'd expect extra calls of). The biggest instruction count change in the frontend I can see in the report is +165,064,649 attributed to ThirBuildCx::make_mirror_unadjusted::{closure}.. paired with -168,609,045 across ThirBuildCx::mirror_expr and ThirBuildCx::mirror_expr_inner; in sum, a small instruction count change for THIR building (less significant than anything else that made it into the report). It also looks like some more instructions were spent allocating space for vectors and hash maps in some places and fewer were spent on that in others. The only significant change seems to be in codegen.

If the llvm perf regression in that test and the incremental perf regression in cranelift-codegen are due to implementation-detail temporaries inheriting expressions' temporary scopes and having their StorageDeads later than necessary (which could definitely affect analyses), I wonder if there's room for some small perf gains by re-scoping those temporaries to have shorter lifetimes. I don't think that would belong in this PR, though.

Kobzol · 2025-09-26T09:43:00Z

This seems like a relatively involved change that indeed could have effect on (LLVM) codegen. I think that in light of that the small regressions are justifiable, especially if you also have some ideas about how it could be improved in the future.

dianne · 2025-09-27T03:33:49Z

I've opened a PR to fix the imprecise array/slice index temporary scopes at #147083. There may be other instances of imprecise temporary scoping in MIR building that this PR would interact with, but that's at least a start.

BoxyUwU · 2025-09-27T21:32:23Z

@dianne I can probably review this PR At Some Point:tm: but it'll take a bit before I have the time to properly dig into the surrounding context of lifetime extension stuff, and I imagine it'll also take a while to get up to speed on that :thinking: If there's someone already up to speed on this that could review this PR that might be better but otherwise this is fine :+1:

dianne · 2025-09-28T01:23:54Z

Unfortunately, I'm not sure who all on review rotation would have lifetime extension fresh in mind. Maybe @jackh726 since you reviewed my last temporary scoping PR recently?
Looking at the compiler team as a whole, cc @m-ou-se @nikomatsakis

Otherwise, thanks in advance! ^^

craterbot · 2025-09-28T04:18:51Z

🚧 Experiment pr-146098 is now running

ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

rustbot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-lang Relevant to the language team labels Sep 1, 2025

This comment has been minimized.

Sign in to view

dianne force-pushed the extending-blocks branch from 78995b7 to 2e55e56 Compare September 1, 2025 17:45

dianne mentioned this pull request Sep 1, 2025

don't apply temporary lifetime extension rules to non-extended super let #145838

Merged

rustbot added the stable-nominated Nominated for backporting to the compiler in the stable channel. label Sep 1, 2025

This comment was marked as off-topic.

Sign in to view

This comment has been minimized.

Sign in to view

dianne force-pushed the extending-blocks branch from 2e55e56 to eafdca9 Compare September 1, 2025 18:34

jieyouxu removed the stable-nominated Nominated for backporting to the compiler in the stable channel. label Sep 2, 2025

traviscross added I-lang-radar Items that are on lang's radar and will need eventual work or consideration. needs-fcp This change is insta-stable, or significant enough to need a team FCP to proceed. labels Sep 2, 2025

rustbot added the stable-nominated Nominated for backporting to the compiler in the stable channel. label Sep 2, 2025

theemathas removed the stable-nominated Nominated for backporting to the compiler in the stable channel. label Sep 2, 2025

dianne and others added 5 commits September 19, 2025 13:20

relocate and reindent record_rvalue_scope_if_borrow_expr

10b76eb

update comment on record_rvalue_scope_if_borrow_expr

1cae2d6

add drop order test for destructuring assignments

3493250

Co-authored-by: Travis Cross <[email protected]>

add test for &format!(...) in an if expression's block

4d1e052

This is the real-world way that the unintentional stabilization of lifetime extension for format arguments was used.

add test for super let in non-extending if blocks

707fd66

dianne changed the title ~~temporary lifetime extension for block tail expressions~~ temporary lifetime extension for blocks Sep 19, 2025

dianne force-pushed the extending-blocks branch from eafdca9 to e649bbe Compare September 19, 2025 23:45

dianne marked this pull request as ready for review September 19, 2025 23:50

rust-bors bot added a commit that referenced this pull request Sep 24, 2025

Auto merge of #146098 - dianne:extending-blocks, r=<try>

028592f

Temporary lifetime extension for blocks

This comment has been minimized.

Sign in to view

craterbot added S-waiting-on-crater Status: Waiting on a crater run to be completed. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Sep 24, 2025

This comment has been minimized.

Sign in to view

rustbot added the S-waiting-on-perf Status: Waiting on a perf run to be completed. label Sep 25, 2025

This comment has been minimized.

Sign in to view

rust-bors bot added a commit that referenced this pull request Sep 25, 2025

Auto merge of #146098 - dianne:extending-blocks, r=<try>

2440211

Temporary lifetime extension for blocks

rust-lang deleted a comment from rust-timer Sep 25, 2025

This comment has been minimized.

Sign in to view

rustbot added perf-regression Performance regression. and removed S-waiting-on-perf Status: Waiting on a perf run to be completed. labels Sep 25, 2025

dianne mentioned this pull request Sep 26, 2025

[beta-1.91] Warn on future errors from temporary lifetimes shortening in Rust 1.92 #147056

Open

Temporary lifetime extension for blocks #146098

Are you sure you want to change the base?

Temporary lifetime extension for blocks #146098

Conversation

dianne commented Sep 1, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

This comment has been minimized.

dianne commented Sep 1, 2025

Uh oh!

This comment was marked as off-topic.

This comment has been minimized.

traviscross commented Sep 2, 2025

Uh oh!

dianne commented Sep 2, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

traviscross commented Sep 2, 2025

Uh oh!

dianne commented Sep 2, 2025

Footnotes

Uh oh!

bors commented Sep 17, 2025

Uh oh!

dianne commented Sep 19, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

traviscross commented Sep 24, 2025

Uh oh!

This comment has been minimized.

rust-bors bot commented Sep 24, 2025

Uh oh!

traviscross commented Sep 24, 2025

Uh oh!

craterbot commented Sep 24, 2025

Uh oh!

traviscross commented Sep 24, 2025

Uh oh!

tgross35 commented Sep 25, 2025

Uh oh!

This comment has been minimized.

Kobzol commented Sep 25, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

This comment has been minimized.

rust-bors bot commented Sep 25, 2025

Uh oh!

This comment has been minimized.

rust-timer commented Sep 25, 2025

Overall result: ❌ regressions - please read the text below

Instruction count

Max RSS (memory usage)

Cycles

Binary size

Uh oh!

dianne commented Sep 25, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Footnotes

Uh oh!

Kobzol commented Sep 25, 2025

Uh oh!

dianne commented Sep 26, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Kobzol commented Sep 26, 2025

Uh oh!

dianne commented Sep 27, 2025

Uh oh!

BoxyUwU commented Sep 27, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

dianne commented Sep 28, 2025

Uh oh!

craterbot commented Sep 28, 2025

Uh oh!

Uh oh!

dianne commented Sep 1, 2025 •

edited

Loading

dianne commented Sep 2, 2025 •

edited

Loading

dianne commented Sep 19, 2025 •

edited

Loading

Kobzol commented Sep 25, 2025 •

edited

Loading

dianne commented Sep 25, 2025 •

edited

Loading

dianne commented Sep 26, 2025 •

edited

Loading

BoxyUwU commented Sep 27, 2025 •

edited

Loading