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 needs to be optimized, 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-21T14:00:23Z

@dianne, with respect to understanding this rule in terms of the Reference's language, what would we be changing in destructors?

If I understand correctly, we'd be extending this temporary

let _x = f({ &temp() });

to live until the end of the statement but not until the end of the surrounding block. So we can't just say, e.g., that trailing expressions of non-extending blocks are extending expressions without saying something else here. Maybe what we're trying to say is that we're walking a chain of extending expressions (which now include trailing expressions of non-extending blocks and ifs), and if the start of the chain is an initializer expression, we extend to the end of the block, and if it's a block or if tail expression, we extend to the end of the enclosing temporary scope. Does that sound right, or how would you think to frame this?

dianne · 2025-09-21T20:57:29Z

The way I've been thinking about it is we'd add a new base case for lifetime extension alongside destructors.scope.lifetime-extension.let and destructors.scope.lifetime-extension.static: informally, lifetime extension would apply to tail expressions of non-extending¹ blocks and to the consequent, else if, and else blocks of non-extending¹ if expressions, where it extends temporaries to the temporary scope of the block or if expression as defined by destructors.scope.temporary.enclosing². We'd also need to change destructors.scope.lifetime-extension.exprs so that the base case isn't specific to let statement initializers³.

The "non-extending" requirement could be removed, but then it would need something else to disambiguate the scope used for extended temporaries in extending blocks' and if expressions' tails. e.g. an additional rule could be added to specify the start of a chain of extending expressions, or it could specify that the largest applicable scope is used, or such. ↩ ↩²
Importantly, this isn't always the end of the statement if the block or if expression is contained within a smaller temporary scope (e.g. the operand of a logical operator, a for loop desugaring, a non-pattern-matching if condition, etc.). ↩
Regardless of this PR, I think this also needs updating account for const and static items' bodies, which are treated like let statement initializers by scope resolution in the compiler and by destructors.scope.lifetime-extension.static. ↩

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

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

rustbot added the T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. label Sep 20, 2025

rustbot assigned BoxyUwU and unassigned nnethercote Sep 20, 2025

traviscross changed the title ~~temporary lifetime extension for blocks~~ Temporary lifetime extension for blocks Sep 20, 2025

traviscross removed the T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. label Sep 22, 2025

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

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 21, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

dianne commented Sep 21, 2025

Footnotes

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!

Uh oh!

dianne commented Sep 1, 2025 •

edited

Loading

dianne commented Sep 2, 2025 •

edited

Loading

dianne commented Sep 19, 2025 •

edited

Loading

traviscross commented Sep 21, 2025 •

edited

Loading

Kobzol commented Sep 25, 2025 •

edited

Loading

dianne commented Sep 25, 2025 •

edited

Loading