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

dianne · 2025-09-26T09:43:26Z

Pursuant to discussion on Zulip, this implements a future-compatibility warning lint macro_extended_temporary_scopes for errors in Rust 1.92 caused by #145838:

warning: temporary lifetime shortening in Rust 1.92
  --> $DIR/macro-extended-temporary-scopes.rs:54:14
   |
LL |             &struct_temp().field
   |              ^^^^^^^^^^^^^ this expression creates a temporary value...
...
LL |         } else {
   |         - ...which will be dropped at the end of this block in Rust 1.92
   |
   = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
   = note: for more information, see <https://doc.rust-lang.org/rustc/lints/listing/warn-by-default.html#macro-extended-temporary-scopes>
   = note: consider using a `let` binding to create a longer lived value

Implementation-wise, this reuses the existing temporary scoping FCW machinery introduced for the tail_expr_drop_order edition lint: this adds BackwardIncompatibleDropHint statements to the MIR at the end of the shortened scopes for affected temporaries; these are then checked in borrowck to warn if the temporary is used after the future drop hint. There are trade-offs here: on one hand, I believe this gives some assurance over ad-hoc pattern-recognition that there are no false positives¹. On the other hand, this fails to lint on future dangling raw pointers and it complicates the potential addition of explanatory diagnostics or suggestions². I'm hopeful that the limitation around dangling pointers won't be relevant in real code, though; the only real instance we've seen of breakage so far is future errors in formatting macro invocations, which this should be able to catch.

Release logistics notes:

This PR targets the beta branch directly, since the breakage it's a FCW for is landing in the next Rust version.
Temporary lifetime extension for blocks #146098 undoes the breakage this is a FCW for. If that behavior is merged and stabilizes in Rust 1.92, this PR should be reverted (or shouldn't be merged) in order to avoid spurious warnings.

cc @traviscross

@rustbot label +T-lang

In particular, more syntactic approaches are complicated by having to avoid warning on promoted constants; they'd either be full of holes, they'd need a lot of extra logic, or they'd need to hack more MIR-to-HIR mapping into PromoteTemps. ↩
It's definitely possible to add more context and a suggestion, but the ways I've thought of to do so are either too hacky or too complex to feel appropriate for a last-minute direct-to-beta lint. ↩

rustbot · 2025-09-26T09:43:29Z

This PR changes MIR

cc @oli-obk, @RalfJung, @JakobDegen, @vakaras

Some changes occurred to MIR optimizations

cc @rust-lang/wg-mir-opt

rustbot · 2025-09-26T09:43:32Z

r? @davidtwco

rustbot has assigned @davidtwco.
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

dianne

A general note: since this isn't targeting master, I've included a fair bit of single-purpose code. It's possible some of the generalizations to BackwardIncompatibleDropHint handling would be good to have for future FCWs, but everything new is made to be one-off and temporary.

Also, a note about the ping for changing the MIR: I believe that's from adding another case to BackwardIncompatibleDropReason.

And about changing MIR transforms: that's from making the significant-drop-reordering part of tail_expr_drop_order only fire on BackwardIncompatibleDropReason::Edition2024. It already checks the edition, so I figure it makes sense to check the BackwardIncompatibleDropReason too.

View changes since this review

dianne · 2025-09-26T09:47:31Z

compiler/rustc_middle/src/thir.rs

-    static_assert_size!(Expr<'_>, 72);
+    static_assert_size!(Expr<'_>, 80);


I believe this should be avoidable. Let me know if it's worth trying to fix.

dianne · 2025-09-26T09:52:16Z

compiler/rustc_lint_defs/src/builtin.rs

+    @future_incompatible = FutureIncompatibleInfo {
+        reason: FutureIncompatibilityReason::FutureReleaseError,
+        reference: "<https://doc.rust-lang.org/rustc/lints/listing/warn-by-default.html#macro-extended-temporary-scopes>",
+    };


Ideally, the reference link shouldn't be tied to the lint's stabilization, but there's not currently a great reference that both includes a complete explanation of the breakage and how to work around it.

Also, I haven't included report_in_deps: true but since the breakage is hitting in the next version it might be warranted.

dianne · 2025-09-26T10:04:54Z

compiler/rustc_borrowck/src/diagnostics/mod.rs

+
+        tcx.node_span_lint(MACRO_EXTENDED_TEMPORARY_SCOPES, lint_root, labels, |diag| {
+            diag.primary_message("temporary lifetime shortening in Rust 1.92");
+            diag.note("consider using a `let` binding to create a longer lived value");


I've opted to use the "consider using a let binding" note from real borrowck diagnostics for simplicity, rather than providing a machine-applicable suggestion. To illustrate, consider real Rust 1.92 nightly diagnostics for the future breakage here:

error[E0716]: temporary value dropped while borrowed --> src/main.rs:18:13 | 18 | pin!({ &temp() }); | --------^^^^^---- | | | | | | | temporary value is freed at the end of this statement | | creates a temporary value which is freed while still in use | borrow later stored here | = note: consider using a `let` binding to create a longer lived value error[E0716]: temporary value dropped while borrowed --> src/main.rs:19:17 | 19 | pin!({ &mut [()] }); | -----^^^- | | | | | | | temporary value is freed at the end of this statement | | creates a temporary value which is freed while still in use | borrow later used here | = note: consider using a `let` binding to create a longer lived value

Note the differing spans. In many instances, the conflicting use reported in diagnostics is an implicit reborrow rather than the actual use in the macro expansion. I think getting more helpful diagnostics would either require:

Improving the actual borrowck diagnostic, then using that machinery.

Forcing maximal MIR-to-HIR mapping via source scopes when forward-incompatible drops are detected, then using bespoke diagnostic information stored earlier in compilation (e.g. the HIR source of forward-incompatible scope extension).

Another awkward aspect of that span imprecision is (without doing either of those things) it's hard to tell when adding a let statement actually can help. In non-pathological cases it should always either help or come with another note that the diagnostic originates in an external macro, so for simplicity, I've opted to always include it.

PatchMixolydic · 2025-09-27T18:02:58Z

compiler/rustc_borrowck/src/diagnostics/mod.rs

+        );
+
+        tcx.node_span_lint(MACRO_EXTENDED_TEMPORARY_SCOPES, lint_root, labels, |diag| {
+            diag.primary_message("temporary lifetime shortening in Rust 1.92");


This message seems like it'd be difficult to understand without context — to me, it almost seems like it's been cut off partway through. It might be better to be explicit here:

Suggested change

diag.primary_message("temporary lifetime shortening in Rust 1.92");

diag.primary_message("this temporary's lifetime will be shortened starting in Rust 1.92");

It is a bit difficult to understand as-is.. though I wonder if there's a way to write it without "this" in the primary message. My original take was "this temporary value's lifetime will shorten in Rust 1.92", but I moved away from it because something didn't feel right to me about the "this" and it felt redundant with the label. Maybe it would be fine?

dianne added 2 commits September 26, 2025 01:39

add positive and negative tests for temporary scope shortening FCW

f1fbf1f

warn on future errors from temporary lifetimes shortening in Rust 1.92

1dc4b0d

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Sep 26, 2025

rustbot assigned davidtwco Sep 26, 2025

rustbot added the T-lang Relevant to the language team label Sep 26, 2025

dianne commented Sep 26, 2025

View reviewed changes

traviscross added I-lang-nominated Nominated for discussion during a lang team meeting. P-lang-drag-0 Lang team prioritization drag level 0.https://rust-lang.zulipchat.com/#narrow/channel/410516-t-lang. labels Sep 26, 2025

PatchMixolydic reviewed Sep 27, 2025

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

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

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

dianne commented Sep 26, 2025 •

edited

Loading

Uh oh!

rustbot commented Sep 26, 2025

Uh oh!

rustbot commented Sep 26, 2025

Uh oh!

dianne left a comment •

edited

Loading

Uh oh!

dianne Sep 26, 2025

Uh oh!

dianne Sep 26, 2025

Uh oh!

dianne Sep 26, 2025 •

edited

Loading

Uh oh!

PatchMixolydic Sep 27, 2025

Uh oh!

dianne Sep 28, 2025

Uh oh!

Uh oh!

		static_assert_size!(Expr<'_>, 72);
		static_assert_size!(Expr<'_>, 80);

	diag.primary_message("temporary lifetime shortening in Rust 1.92");
	diag.primary_message("this temporary's lifetime will be shortened starting in Rust 1.92");

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

Are you sure you want to change the base?

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

Conversation

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

Uh oh!

Footnotes

Uh oh!

rustbot commented Sep 26, 2025

Uh oh!

rustbot commented Sep 26, 2025

Uh oh!

dianne left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dianne Sep 26, 2025

Choose a reason for hiding this comment

Uh oh!

dianne Sep 26, 2025

Choose a reason for hiding this comment

Uh oh!

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

Uh oh!

Choose a reason for hiding this comment

Uh oh!

PatchMixolydic Sep 27, 2025

Choose a reason for hiding this comment

Uh oh!

dianne Sep 28, 2025

Choose a reason for hiding this comment

Uh oh!

Uh oh!

dianne commented Sep 26, 2025 •

edited

Loading

dianne left a comment •

edited

Loading

dianne Sep 26, 2025 •

edited

Loading