add a scope for `if let` guard temporaries and bindings #143376

dianne · 2025-07-03T14:18:26Z

This fixes my concern with if let guard drop order, namely that the guard's bindings and temporaries were being dropped after their arm's pattern's bindings, instead of before (#141295 (comment)). The guard's bindings and temporaries now live in a new scope, which extends until (but not past) the end of the arm, guaranteeing they're dropped before the arm's pattern's bindings.

This only introduces a new scope for match arms with guards. Perf results (#143376 (comment)) seemed to indicate there wasn't a significant hit to introduce a new scope on all match arms, but guard patterns (#129967) will likely benefit from only adding new scopes when necessary (with some patterns requiring multiple nested scopes).

Tracking issue for if_let_guard: #51114

Tests are adapted from examples by @traviscross, @est31, and myself on #141295.

rustbot · 2025-07-03T14:18:32Z

Nadrieril is not on the review rotation at the moment.
They may take a while to respond.

rustbot · 2025-07-03T14:18:34Z

Some changes occurred in match lowering

cc @Nadrieril

traviscross · 2025-07-03T17:55:05Z

All sounds reasonable to me. Let's see what perf thinks.

@bors2 try
@rust-timer queue

rust-bors · 2025-07-03T17:55:09Z

⌛ Trying commit f501cdd with merge 43cc1e1…

To cancel the try build, run the command @bors2 try cancel.

add a scope for `if let` guard temporaries and bindings This fixes my concern with `if let` guard drop order, namely that the guard's bindings and temporaries were being dropped after their arm's pattern's bindings, instead of before (#141295 (comment)). The guard's bindings and temporaries now live in a new scope, which extends until (but not past) the end of the arm, guaranteeing they're dropped before the arm's pattern's bindings. So far, this is the only way I've thought of to achieve this without explicitly rescheduling guards' drops to move them after the arm's pattern's. I'm not sure this should be merged as-is. It's a little hacky and it introduces a new scope for *all* match arms rather than just those with `if let` guards. However, since I'm looking for feedback on the approach, I figured this is a relatively simple way to present it. As I mention in a FIXME comment, something like this will be needed for guard patterns (#129967) too[^1], so I think the final version should maybe only add these scopes as needed. That'll be better for perf too. Tracking issue for `if_let_guard`: #51114 Tests are adapted from examples by `@traviscross,` `@est31,` and myself on #141295. cc, as I'd like your input on this. I'm not entirely sure who to request for scoping changes, but let's start with r? `@Nadrieril` since this relates to guard patterns, we talked about it recently, and rustbot's going to ping you anyway. Feel free to reassign! [^1]: e.g., new scopes are needed to keep failed guards inside `let` chain patterns from dropping existing bindings/temporaries; something like this could give a way of doing that without needing to reschedule drops. Unfortunately it may not help keep failed guards in `let` statement patterns from dropping the `let` statement's initializer, so it isn't a complete solution. I'm still not sure how to do that without rescheduling drops, changing how `let` statements' scopes work, or restricting the functionality of guard patterns in `let` statements (including `let`-`else`).

rust-bors · 2025-07-03T20:10:30Z

☀️ Try build successful (CI)
Build commit: 43cc1e1 (43cc1e156c2be744a9205d52fabf2fdff36c6ee2, parent: a413f77285c0ab551cf58db729e054f43150dd50)

rust-timer · 2025-07-04T08:10:56Z

Finished benchmarking commit (43cc1e1): 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
Improvements ✅ (primary)	-2.9%	[-2.9%, -2.9%]	1
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-2.9%	[-2.9%, -2.9%]	1

Max RSS (memory usage)

Results (primary 2.0%, secondary 2.8%)

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

	mean	range	count
Regressions ❌ (primary)	3.6%	[1.7%, 5.6%]	2
Regressions ❌ (secondary)	2.8%	[2.2%, 3.4%]	2
Improvements ✅ (primary)	-1.4%	[-1.4%, -1.4%]	1
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	2.0%	[-1.4%, 5.6%]	3

Cycles

Results (primary -3.1%, secondary -0.7%)

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)	2.1%	[1.0%, 3.2%]	2
Improvements ✅ (primary)	-3.1%	[-3.4%, -2.7%]	2
Improvements ✅ (secondary)	-2.5%	[-6.0%, -0.7%]	3
All ❌✅ (primary)	-3.1%	[-3.4%, -2.7%]	2

Binary size

Results (primary -1.1%)

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)	-1.1%	[-1.1%, -1.1%]	1
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-1.1%	[-1.1%, -1.1%]	1

Bootstrap: 461.296s -> 461.485s (0.04%)
Artifact size: 372.12 MiB -> 372.20 MiB (0.02%)

dianne · 2025-07-04T09:09:08Z

Looks like noise. If there was a change, it would be a regression in region_scope_tree, thir_body, or mir_built, which I'm not seeing. Likewise, this will result in a bit more memory usage when going from HIR to MIR, but it also seems to be lost in noise, at least as far as I can tell from the graphs.

Nadrieril · 2025-07-05T15:15:42Z

I approve of the idea! Can't speak of the impl, I'm not familiar with MIR scopes.

r? compiler

tests/ui/drop/if-let-guards.rs

lower pattern bindings in the order they're written and base drop order on primary bindings' order To fix #142163, this PR does two things: - Makes match arms base their drop order on the first sub-branch instead of the last sub-branch. Together with the second change, this makes bindings' drop order correspond to the relative order of when each binding first appears (i.e. the order of the "primary" bindings). - Lowers pattern bindings in the order they're written (still treating the right-hand side of a ``@`` as coming before the binding on the left). In each sub-branch of a match arm, this is the order that would be obtained if the or-alternatives chosen in that sub-branch were inlined into the arm's pattern. This both affects drop order (making bindings in or-patterns not be dropped first) and fixes the issue in [this test](https://github.com/rust-lang/rust/blob/2a023bf80a6fbd6a06d5460a34eb247b986286ed/tests/ui/pattern/bindings-after-at/bind-by-copy-or-pat.rs) from #121716. My approach to the second point is admittedly a bit trickier than may be necessary. To avoid passing around a counter when building `FlatPat`s, I've instead added just enough information to recover the original structure of the pattern's bindings from a `MatchTreeSubBranch`'s path through the `Candidate` tree. Some alternatives: - We could use a counter, then sort bindings by their ordinals when making `MatchTreeSubBranch`es. - I'd like to experiment with always merging sub-candidates and removing `test_remaining_match_pairs_after_or`; that would require lowering bindings and guards in a different way. That makes it a bigger change too, though, so I figure it might be simplest to start here. - For a very big change, we could track which or-alternatives succeed at runtime to base drop order on the binding order in the particular alternatives matched. This is a breaking change. It will need a crater run, language team sign-off, and likely updates to the Reference. This will conflict with #143376 and probably also #143028, so they shouldn't be merged at the same time. r? `@matthewjasper` or `@Nadrieril`

… r=Nadrieril,traviscross lower pattern bindings in the order they're written and base drop order on primary bindings' order To fix rust-lang#142163, this PR does two things: - Makes match arms base their drop order on the first sub-branch instead of the last sub-branch. Together with the second change, this makes bindings' drop order correspond to the relative order of when each binding first appears (i.e. the order of the "primary" bindings). - Lowers pattern bindings in the order they're written (still treating the right-hand side of a ``@`` as coming before the binding on the left). In each sub-branch of a match arm, this is the order that would be obtained if the or-alternatives chosen in that sub-branch were inlined into the arm's pattern. This both affects drop order (making bindings in or-patterns not be dropped first) and fixes the issue in [this test](https://github.com/rust-lang/rust/blob/2a023bf80a6fbd6a06d5460a34eb247b986286ed/tests/ui/pattern/bindings-after-at/bind-by-copy-or-pat.rs) from rust-lang#121716. My approach to the second point is admittedly a bit trickier than may be necessary. To avoid passing around a counter when building `FlatPat`s, I've instead added just enough information to recover the original structure of the pattern's bindings from a `MatchTreeSubBranch`'s path through the `Candidate` tree. Some alternatives: - We could use a counter, then sort bindings by their ordinals when making `MatchTreeSubBranch`es. - I'd like to experiment with always merging sub-candidates and removing `test_remaining_match_pairs_after_or`; that would require lowering bindings and guards in a different way. That makes it a bigger change too, though, so I figure it might be simplest to start here. - For a very big change, we could track which or-alternatives succeed at runtime to base drop order on the binding order in the particular alternatives matched. This is a breaking change. It will need a crater run, language team sign-off, and likely updates to the Reference. This will conflict with rust-lang#143376 and probably also rust-lang#143028, so they shouldn't be merged at the same time. r? `@matthewjasper` or `@Nadrieril`

… r=Nadrieril,traviscross lower pattern bindings in the order they're written and base drop order on primary bindings' order To fix rust-lang#142163, this PR does two things: - Makes match arms base their drop order on the first sub-branch instead of the last sub-branch. Together with the second change, this makes bindings' drop order correspond to the relative order of when each binding first appears (i.e. the order of the "primary" bindings). - Lowers pattern bindings in the order they're written (still treating the right-hand side of a ```@``` as coming before the binding on the left). In each sub-branch of a match arm, this is the order that would be obtained if the or-alternatives chosen in that sub-branch were inlined into the arm's pattern. This both affects drop order (making bindings in or-patterns not be dropped first) and fixes the issue in [this test](https://github.com/rust-lang/rust/blob/2a023bf80a6fbd6a06d5460a34eb247b986286ed/tests/ui/pattern/bindings-after-at/bind-by-copy-or-pat.rs) from rust-lang#121716. My approach to the second point is admittedly a bit trickier than may be necessary. To avoid passing around a counter when building `FlatPat`s, I've instead added just enough information to recover the original structure of the pattern's bindings from a `MatchTreeSubBranch`'s path through the `Candidate` tree. Some alternatives: - We could use a counter, then sort bindings by their ordinals when making `MatchTreeSubBranch`es. - I'd like to experiment with always merging sub-candidates and removing `test_remaining_match_pairs_after_or`; that would require lowering bindings and guards in a different way. That makes it a bigger change too, though, so I figure it might be simplest to start here. - For a very big change, we could track which or-alternatives succeed at runtime to base drop order on the binding order in the particular alternatives matched. This is a breaking change. It will need a crater run, language team sign-off, and likely updates to the Reference. This will conflict with rust-lang#143376 and probably also rust-lang#143028, so they shouldn't be merged at the same time. r? ``@matthewjasper`` or ``@Nadrieril``

… r=Nadrieril,traviscross lower pattern bindings in the order they're written and base drop order on primary bindings' order To fix rust-lang#142163, this PR does two things: - Makes match arms base their drop order on the first sub-branch instead of the last sub-branch. Together with the second change, this makes bindings' drop order correspond to the relative order of when each binding first appears (i.e. the order of the "primary" bindings). - Lowers pattern bindings in the order they're written (still treating the right-hand side of a ````@```` as coming before the binding on the left). In each sub-branch of a match arm, this is the order that would be obtained if the or-alternatives chosen in that sub-branch were inlined into the arm's pattern. This both affects drop order (making bindings in or-patterns not be dropped first) and fixes the issue in [this test](https://github.com/rust-lang/rust/blob/2a023bf80a6fbd6a06d5460a34eb247b986286ed/tests/ui/pattern/bindings-after-at/bind-by-copy-or-pat.rs) from rust-lang#121716. My approach to the second point is admittedly a bit trickier than may be necessary. To avoid passing around a counter when building `FlatPat`s, I've instead added just enough information to recover the original structure of the pattern's bindings from a `MatchTreeSubBranch`'s path through the `Candidate` tree. Some alternatives: - We could use a counter, then sort bindings by their ordinals when making `MatchTreeSubBranch`es. - I'd like to experiment with always merging sub-candidates and removing `test_remaining_match_pairs_after_or`; that would require lowering bindings and guards in a different way. That makes it a bigger change too, though, so I figure it might be simplest to start here. - For a very big change, we could track which or-alternatives succeed at runtime to base drop order on the binding order in the particular alternatives matched. This is a breaking change. It will need a crater run, language team sign-off, and likely updates to the Reference. This will conflict with rust-lang#143376 and probably also rust-lang#143028, so they shouldn't be merged at the same time. r? ```@matthewjasper``` or ```@Nadrieril```

… r=Nadrieril,traviscross lower pattern bindings in the order they're written and base drop order on primary bindings' order To fix rust-lang#142163, this PR does two things: - Makes match arms base their drop order on the first sub-branch instead of the last sub-branch. Together with the second change, this makes bindings' drop order correspond to the relative order of when each binding first appears (i.e. the order of the "primary" bindings). - Lowers pattern bindings in the order they're written (still treating the right-hand side of a ``@`` as coming before the binding on the left). In each sub-branch of a match arm, this is the order that would be obtained if the or-alternatives chosen in that sub-branch were inlined into the arm's pattern. This both affects drop order (making bindings in or-patterns not be dropped first) and fixes the issue in [this test](https://github.com/rust-lang/rust/blob/2a023bf80a6fbd6a06d5460a34eb247b986286ed/tests/ui/pattern/bindings-after-at/bind-by-copy-or-pat.rs) from rust-lang#121716. My approach to the second point is admittedly a bit trickier than may be necessary. To avoid passing around a counter when building `FlatPat`s, I've instead added just enough information to recover the original structure of the pattern's bindings from a `MatchTreeSubBranch`'s path through the `Candidate` tree. Some alternatives: - We could use a counter, then sort bindings by their ordinals when making `MatchTreeSubBranch`es. - I'd like to experiment with always merging sub-candidates and removing `test_remaining_match_pairs_after_or`; that would require lowering bindings and guards in a different way. That makes it a bigger change too, though, so I figure it might be simplest to start here. - For a very big change, we could track which or-alternatives succeed at runtime to base drop order on the binding order in the particular alternatives matched. This is a breaking change. It will need a crater run, language team sign-off, and likely updates to the Reference. This will conflict with rust-lang#143376 and probably also rust-lang#143028, so they shouldn't be merged at the same time. r? `@matthewjasper` or `@Nadrieril`

… r=Nadrieril,traviscross lower pattern bindings in the order they're written and base drop order on primary bindings' order To fix rust-lang#142163, this PR does two things: - Makes match arms base their drop order on the first sub-branch instead of the last sub-branch. Together with the second change, this makes bindings' drop order correspond to the relative order of when each binding first appears (i.e. the order of the "primary" bindings). - Lowers pattern bindings in the order they're written (still treating the right-hand side of a ```@``` as coming before the binding on the left). In each sub-branch of a match arm, this is the order that would be obtained if the or-alternatives chosen in that sub-branch were inlined into the arm's pattern. This both affects drop order (making bindings in or-patterns not be dropped first) and fixes the issue in [this test](https://github.com/rust-lang/rust/blob/2a023bf80a6fbd6a06d5460a34eb247b986286ed/tests/ui/pattern/bindings-after-at/bind-by-copy-or-pat.rs) from rust-lang#121716. My approach to the second point is admittedly a bit trickier than may be necessary. To avoid passing around a counter when building `FlatPat`s, I've instead added just enough information to recover the original structure of the pattern's bindings from a `MatchTreeSubBranch`'s path through the `Candidate` tree. Some alternatives: - We could use a counter, then sort bindings by their ordinals when making `MatchTreeSubBranch`es. - I'd like to experiment with always merging sub-candidates and removing `test_remaining_match_pairs_after_or`; that would require lowering bindings and guards in a different way. That makes it a bigger change too, though, so I figure it might be simplest to start here. - For a very big change, we could track which or-alternatives succeed at runtime to base drop order on the binding order in the particular alternatives matched. This is a breaking change. It will need a crater run, language team sign-off, and likely updates to the Reference. This will conflict with rust-lang#143376 and probably also rust-lang#143028, so they shouldn't be merged at the same time. r? ``@matthewjasper`` or ``@Nadrieril``

… r=Nadrieril,traviscross lower pattern bindings in the order they're written and base drop order on primary bindings' order To fix rust-lang#142163, this PR does two things: - Makes match arms base their drop order on the first sub-branch instead of the last sub-branch. Together with the second change, this makes bindings' drop order correspond to the relative order of when each binding first appears (i.e. the order of the "primary" bindings). - Lowers pattern bindings in the order they're written (still treating the right-hand side of a ````@```` as coming before the binding on the left). In each sub-branch of a match arm, this is the order that would be obtained if the or-alternatives chosen in that sub-branch were inlined into the arm's pattern. This both affects drop order (making bindings in or-patterns not be dropped first) and fixes the issue in [this test](https://github.com/rust-lang/rust/blob/2a023bf80a6fbd6a06d5460a34eb247b986286ed/tests/ui/pattern/bindings-after-at/bind-by-copy-or-pat.rs) from rust-lang#121716. My approach to the second point is admittedly a bit trickier than may be necessary. To avoid passing around a counter when building `FlatPat`s, I've instead added just enough information to recover the original structure of the pattern's bindings from a `MatchTreeSubBranch`'s path through the `Candidate` tree. Some alternatives: - We could use a counter, then sort bindings by their ordinals when making `MatchTreeSubBranch`es. - I'd like to experiment with always merging sub-candidates and removing `test_remaining_match_pairs_after_or`; that would require lowering bindings and guards in a different way. That makes it a bigger change too, though, so I figure it might be simplest to start here. - For a very big change, we could track which or-alternatives succeed at runtime to base drop order on the binding order in the particular alternatives matched. This is a breaking change. It will need a crater run, language team sign-off, and likely updates to the Reference. This will conflict with rust-lang#143376 and probably also rust-lang#143028, so they shouldn't be merged at the same time. r? ```@matthewjasper``` or ```@Nadrieril```

Rollup merge of #143764 - dianne:primary-binding-drop-order, r=Nadrieril,traviscross lower pattern bindings in the order they're written and base drop order on primary bindings' order To fix #142163, this PR does two things: - Makes match arms base their drop order on the first sub-branch instead of the last sub-branch. Together with the second change, this makes bindings' drop order correspond to the relative order of when each binding first appears (i.e. the order of the "primary" bindings). - Lowers pattern bindings in the order they're written (still treating the right-hand side of a ``@`` as coming before the binding on the left). In each sub-branch of a match arm, this is the order that would be obtained if the or-alternatives chosen in that sub-branch were inlined into the arm's pattern. This both affects drop order (making bindings in or-patterns not be dropped first) and fixes the issue in [this test](https://github.com/rust-lang/rust/blob/2a023bf80a6fbd6a06d5460a34eb247b986286ed/tests/ui/pattern/bindings-after-at/bind-by-copy-or-pat.rs) from #121716. My approach to the second point is admittedly a bit trickier than may be necessary. To avoid passing around a counter when building `FlatPat`s, I've instead added just enough information to recover the original structure of the pattern's bindings from a `MatchTreeSubBranch`'s path through the `Candidate` tree. Some alternatives: - We could use a counter, then sort bindings by their ordinals when making `MatchTreeSubBranch`es. - I'd like to experiment with always merging sub-candidates and removing `test_remaining_match_pairs_after_or`; that would require lowering bindings and guards in a different way. That makes it a bigger change too, though, so I figure it might be simplest to start here. - For a very big change, we could track which or-alternatives succeed at runtime to base drop order on the binding order in the particular alternatives matched. This is a breaking change. It will need a crater run, language team sign-off, and likely updates to the Reference. This will conflict with #143376 and probably also #143028, so they shouldn't be merged at the same time. r? `@matthewjasper` or `@Nadrieril`

bors · 2025-08-07T17:51:56Z

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

This ensures `if let` guard temporaries and bindings are dropped before the match arm's pattern's bindings.

dianne · 2025-08-08T00:06:23Z

Rebased, cleaned up a little, tweaked comments, updated the PR description, and made it so only match arms with guards introduce a new scope. I think this is ready for review now. r? @matthewjasper or reassign

…ril,traviscross lower pattern bindings in the order they're written and base drop order on primary bindings' order To fix rust-lang/rust#142163, this PR does two things: - Makes match arms base their drop order on the first sub-branch instead of the last sub-branch. Together with the second change, this makes bindings' drop order correspond to the relative order of when each binding first appears (i.e. the order of the "primary" bindings). - Lowers pattern bindings in the order they're written (still treating the right-hand side of a ``@`` as coming before the binding on the left). In each sub-branch of a match arm, this is the order that would be obtained if the or-alternatives chosen in that sub-branch were inlined into the arm's pattern. This both affects drop order (making bindings in or-patterns not be dropped first) and fixes the issue in [this test](https://github.com/rust-lang/rust/blob/2a023bf80a6fbd6a06d5460a34eb247b986286ed/tests/ui/pattern/bindings-after-at/bind-by-copy-or-pat.rs) from rust-lang/rust#121716. My approach to the second point is admittedly a bit trickier than may be necessary. To avoid passing around a counter when building `FlatPat`s, I've instead added just enough information to recover the original structure of the pattern's bindings from a `MatchTreeSubBranch`'s path through the `Candidate` tree. Some alternatives: - We could use a counter, then sort bindings by their ordinals when making `MatchTreeSubBranch`es. - I'd like to experiment with always merging sub-candidates and removing `test_remaining_match_pairs_after_or`; that would require lowering bindings and guards in a different way. That makes it a bigger change too, though, so I figure it might be simplest to start here. - For a very big change, we could track which or-alternatives succeed at runtime to base drop order on the binding order in the particular alternatives matched. This is a breaking change. It will need a crater run, language team sign-off, and likely updates to the Reference. This will conflict with rust-lang/rust#143376 and probably also rust-lang/rust#143028, so they shouldn't be merged at the same time. r? `@matthewjasper` or `@Nadrieril`

matthewjasper · 2025-08-08T15:29:52Z

@bors r+

bors · 2025-08-08T15:29:55Z

📌 Commit 0bdaef5 has been approved by matthewjasper

It is now in the queue for this repository.

bors · 2025-08-08T17:09:13Z

⌛ Testing commit 0bdaef5 with merge a9447e2...

add a scope for `if let` guard temporaries and bindings This fixes my concern with `if let` guard drop order, namely that the guard's bindings and temporaries were being dropped after their arm's pattern's bindings, instead of before (#141295 (comment)). The guard's bindings and temporaries now live in a new scope, which extends until (but not past) the end of the arm, guaranteeing they're dropped before the arm's pattern's bindings. This only introduces a new scope for match arms with guards. Perf results (#143376 (comment)) seemed to indicate there wasn't a significant hit to introduce a new scope on all match arms, but guard patterns (#129967) will likely benefit from only adding new scopes when necessary (with some patterns requiring multiple nested scopes). Tracking issue for `if_let_guard`: #51114 Tests are adapted from examples by `@traviscross,` `@est31,` and myself on #141295.

Kobzol · 2025-08-08T17:12:40Z

Cancelled the build due to #144787 (comment).

bors · 2025-08-08T17:12:55Z

💔 Test failed - checks-actions

Kobzol · 2025-08-08T20:53:12Z

@bors retry

bors · 2025-08-09T03:19:29Z

⌛ Testing commit 0bdaef5 with merge 2de2456...

bors · 2025-08-09T06:21:47Z

☀️ Test successful - checks-actions
Approved by: matthewjasper
Pushing 2de2456 to master...

github-actions · 2025-08-09T06:25:01Z

What is this?

This is an experimental post-merge analysis report that shows differences in test outcomes between the merged PR and its parent PR.

Comparing 4c7749e (parent) -> 2de2456 (this PR)

Test differences

Show 42 test diffs

Stage 1

[ui] tests/ui/drop/if-let-guards.rs#e2021: [missing] -> pass (J1)
[ui] tests/ui/drop/if-let-guards.rs#e2024: [missing] -> pass (J1)

Stage 2

[ui] tests/ui/drop/if-let-guards.rs#e2021: [missing] -> pass (J0)
[ui] tests/ui/drop/if-let-guards.rs#e2024: [missing] -> pass (J0)

Additionally, 38 doctest diffs were found. These are ignored, as they are noisy.

Job group index

Test dashboard

Run

cargo run --manifest-path src/ci/citool/Cargo.toml -- \
    test-dashboard 2de2456fb7b2b55cb104bb03f30edd145c6015a3 --output-dir test-dashboard

And then open test-dashboard/index.html in your browser to see an overview of all executed tests.

Job duration changes

dist-apple-various: 5161.2s -> 3785.5s (-26.7%)
dist-aarch64-linux: 8124.8s -> 6209.9s (-23.6%)
x86_64-apple-2: 5180.1s -> 6111.9s (18.0%)
pr-check-1: 1606.9s -> 1805.2s (12.3%)
x86_64-apple-1: 8363.6s -> 7340.0s (-12.2%)
dist-i586-gnu-i586-i686-musl: 5487.3s -> 6153.7s (12.1%)
dist-s390x-linux: 4863.2s -> 5351.3s (10.0%)
dist-x86_64-windows-gnullvm: 5569.8s -> 6126.0s (10.0%)
dist-arm-linux-gnueabi: 4742.7s -> 5174.4s (9.1%)
dist-powerpc64-linux: 5107.8s -> 5549.8s (8.7%)

How to interpret the job duration changes?

Job durations can vary a lot, based on the actual runner instance
that executed the job, system noise, invalidated caches, etc. The table above is provided
mostly for t-infra members, for simpler debugging of potential CI slow-downs.

rust-timer · 2025-08-09T07:32:29Z

Finished benchmarking commit (2de2456): comparison URL.

Overall result: ❌ regressions - no action needed

@rustbot label: -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.6%	[0.6%, 0.6%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-	-	0

Max RSS (memory usage)

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

Cycles

Results (secondary 2.4%)

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)	2.4%	[2.4%, 2.4%]	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: 463.02s -> 463.949s (0.20%)
Artifact size: 377.40 MiB -> 377.40 MiB (-0.00%)

rustbot assigned Nadrieril Jul 3, 2025

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 Jul 3, 2025

dianne force-pushed the guard-scope branch from 21d2e81 to f501cdd Compare July 3, 2025 14:36

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 Jul 3, 2025

This comment has been minimized.

Sign in to view

rustbot removed the S-waiting-on-perf Status: Waiting on a perf run to be completed. label Jul 4, 2025

rustbot assigned compiler-errors and unassigned Nadrieril Jul 5, 2025

est31 reviewed Jul 5, 2025

View reviewed changes

tests/ui/drop/if-let-guards.rs Outdated Show resolved Hide resolved

dianne force-pushed the guard-scope branch from f501cdd to 8e5580a Compare July 6, 2025 00:48

dianne mentioned this pull request Jul 11, 2025

lower pattern bindings in the order they're written and base drop order on primary bindings' order #143764

Merged

traviscross added the I-lang-radar Items that are on lang's radar and will need eventual work or consideration. label Jul 23, 2025

dianne added 3 commits August 7, 2025 16:19

add more tests for if let guard drop order

4ec6881

add a scope for if let guard temporaries and bindings

b2241c7

This ensures `if let` guard temporaries and bindings are dropped before the match arm's pattern's bindings.

only introduce a guard scope for arms with guards

0bdaef5

dianne force-pushed the guard-scope branch from 8e5580a to 0bdaef5 Compare August 7, 2025 23:55

rustbot assigned matthewjasper and unassigned compiler-errors Aug 8, 2025

bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Aug 8, 2025

bors added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Aug 8, 2025

bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Aug 8, 2025

bors added the merged-by-bors This PR was explicitly merged by bors. label Aug 9, 2025

bors merged commit 2de2456 into rust-lang:master Aug 9, 2025
11 checks passed

rustbot added this to the 1.91.0 milestone Aug 9, 2025

add a scope for if let guard temporaries and bindings #143376

add a scope for if let guard temporaries and bindings #143376

Conversation

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

Uh oh!

Uh oh!

rustbot commented Jul 3, 2025

Uh oh!

rustbot commented Jul 3, 2025

Uh oh!

traviscross commented Jul 3, 2025

Uh oh!

This comment has been minimized.

rust-bors bot commented Jul 3, 2025

Uh oh!

rust-bors bot commented Jul 3, 2025

Uh oh!

This comment has been minimized.

rust-timer commented Jul 4, 2025

Overall result: ✅ improvements - no action needed

Uh oh!

dianne commented Jul 4, 2025

Uh oh!

Nadrieril commented Jul 5, 2025

Uh oh!

Uh oh!

bors commented Aug 7, 2025

Uh oh!

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

Uh oh!

Uh oh!

matthewjasper commented Aug 8, 2025

Uh oh!

bors commented Aug 8, 2025

Uh oh!

bors commented Aug 8, 2025

Uh oh!

Kobzol commented Aug 8, 2025

Uh oh!

bors commented Aug 8, 2025

Uh oh!

Kobzol commented Aug 8, 2025

Uh oh!

bors commented Aug 9, 2025

Uh oh!

bors commented Aug 9, 2025

Uh oh!

Uh oh!

github-actions bot commented Aug 9, 2025

Test differences

Stage 1

Stage 2

Job duration changes

Uh oh!

rust-timer commented Aug 9, 2025

Overall result: ❌ regressions - no action needed

Uh oh!

Uh oh!

add a scope for `if let` guard temporaries and bindings #143376

add a scope for `if let` guard temporaries and bindings #143376

dianne commented Jul 3, 2025 •

edited

Loading

dianne commented Aug 8, 2025 •

edited

Loading