Make closure capturing have consistent and correct behaviour around patterns #138961

meithecatte · 2025-03-26T02:59:42Z

Reference PR:

Document how closure capturing interacts with discriminant reads reference#1837

This PR has two goals:

firstly, it fixes internal compiler error: two identical projections #137467. In order to do so, it needs to introduce a small breaking change surrounding the interaction of closure captures with matching against enums with uninhabited variants. Yes – to fix an ICE!
- this also fixes ICE: called Option::unwrap() on a None value with refutable patterns #138973, a slightly different case with the same root cause.
- likewise, fixes ICE: upvar: assertion failed: 1 == 2 -Wrust-2021-incompatible-closure-captures #140011.
secondly, it fixes Closure captures are inconsistent between x and x @ _ irrefutable patterns #137553, making the closure capturing rules consistent between let patterns and match patterns. This is new insta-stable behavior.

Background

This change concerns how precise closure captures interact with patterns. As a little known feature, patterns that require inspecting only part of a value will only cause that part of the value to get captured:

fn main() {
    let mut a = (21, 37);
    // only captures a.0, writing to a.1 does not invalidate the closure
    let mut f = || {
        let (ref mut x, _) = a;
        *x = 42;
    };
    a.1 = 69;
    f();
}

I was not able to find any discussion of this behavior being introduced, or discussion of its edge-cases, but it is documented in the Rust reference.

The currently stable behavior is as follows:

if any pattern contains a binding, the place it binds gets captured (implemented in current walk_pat)
patterns in refutable positions (match, if let, let ... else, but not destructuring let or destructuring function parameters) get processed as follows (maybe_read_scrutinee):
- if matching against the pattern will at any point require inspecting a discriminant, or it includes a variable binding not followed by an @-pattern, capture the entire scrutinee by reference

You will note that this behavior is quite weird and it's hard to imagine a sensible rationale for at least some of its aspects. It has the following issues:

firstly, it assumes that matching against an irrefutable pattern cannot possibly require inspecting any discriminants. With or-patterns, this isn't true, and it is the cause of the internal compiler error: two identical projections #137467 ICE.
secondly, the presence of an @-pattern doesn't really have any semantics by itself. This is the weird behavior tracked as Closure captures are inconsistent between x and x @ _ irrefutable patterns #137553.
thirdly, the behavior is different between pattern-matching done through let and pattern-matching done through match – which is a superficial syntactic difference

This PR aims to address all of the above issues. The new behavior is as follows:

like before, if a pattern contains a binding, the place it binds gets captured as required by the binding mode
if matching against the pattern requires inspecting a disciminant, the place whose discriminant needs to be inspected gets captured by reference

"requires inspecting a discriminant" is also used here to mean "compare something with a constant" and other such decisions. For types other than ADTs, the details are not interesting and aren't changing.

The breaking change

During closure capture analysis, matching an enum against a constructor is considered to require inspecting a discriminant if the enum has more than one variant. Notably, this is the case even if all the other variants happen to be uninhabited. This is motivated by implementation difficulties involved in querying whether types are inhabited before we're done with type inference – without moving mountains to make it happen, you hit this assert:

rust/compiler/rustc_middle/src/ty/inhabitedness/mod.rs

Line 121 in 43f0014

debug_assert!(!self.has_infer());

Now, because the previous implementation did not concern itself with capturing the discriminants for irrefutable patterns at all, this is a breaking change – the following example, adapted from the testsuite, compiles on current stable, but will not compile with this PR:

#[derive(Clone, Copy, PartialEq, Eq, Debug)]
enum Void {}

pub fn main() {
    let mut r = Result::<Void, (u32, u32)>::Err((0, 0));
    let mut f = || {
        let Err((ref mut a, _)) = r;
        *a = 1;
    };
    let mut g = || {
    //~^ ERROR: cannot borrow `r` as mutable more than once at a time
        let Err((_, ref mut b)) = r;
        *b = 2;
    };
    f();
    g();
    assert_eq!(r, Err((1, 2)));
}

Is the breaking change necessary?

One other option would be to double down, and introduce a set of syntactic rules for determining whether a sub-pattern is in an irrefutable position, instead of querying the types and checking how many variants there are.

This would not eliminate the breaking change, but it would limit it to more contrived examples, such as

let ((true, Err((ref mut a, _, _))) | (false, Err((_, ref mut a, _)))) = x;

In this example, the Errs would not be considered in an irrefutable position, because they are part of an or-pattern. However, current stable would treat this just like a tuple (bool, (T, U, _)).

While introducing such a distinction would limit the impact, I would say that the added complexity would not be commensurate with the benefit it introduces.

The new insta-stable behavior

If a pattern in a match expression or similar has parts it will never read, this part will not be captured anymore:

fn main() {
    let mut a = (21, 37);
    // now only captures a.0, instead of the whole a
    let mut f = || {
        match a {
            (ref mut x, _) => *x = 42,
        }
    };
    a.1 = 69;
    f();
}

Note that this behavior was pretty much already present, but only accessible with this One Weird Trick™:

fn main() {
    let mut a = (21, 37);
    // both stable and this PR only capture a.0, because of the no-op @-pattern
    let mut f = || {
        match a {
            (ref mut x @ _, _) => *x = 42,
        }
    };
    a.1 = 69;
    f();
}

The second, more practically-relevant breaking change

After running crater, we have discovered that the aforementioned insta-stable behavior, where sometimes closures will now capture less, can also manifest as a breaking change. This is because it is possible that previously a closure would capture an entire struct by-move, and now it'll start capturing only part of it – some by move, and some by reference. This then causes the closure to have a more restrictive lifetime than it did previously.

See:

Implementation notes

The PR has two main commits:

"ExprUseVisitor: properly report discriminant reads" makes walk_pat perform all necessary capturing. This is the part that fixes internal compiler error: two identical projections #137467.
"ExprUseVisitor: remove maybe_read_scrutinee" removes the unnecessary "capture the entire scrutinee" behavior, fixing Closure captures are inconsistent between x and x @ _ irrefutable patterns #137553.

The new logic stops making the distinction between one particular example that used to work, and another ICE, tracked as #119786. As this requires an unstable feature, I am leaving this as future work.

rustbot · 2025-03-26T17:28:34Z

This PR changes a file inside tests/crashes. If a crash was fixed, please move into the corresponding ui subdir and add 'Fixes #' to the PR description to autoclose the issue upon merge.

meithecatte · 2025-03-26T17:32:16Z

Nadrieril suggested that this should be resolved through a breaking change – updated the PR description accordingly.

@rustbot label +needs-crater

r? @Nadrieril

rustbot · 2025-03-26T17:32:19Z

Error: Label needs-crater can only be set by Rust team members

Please file an issue on GitHub at triagebot if there's a problem with this bot, or reach out on #t-infra on Zulip.

meithecatte · 2025-03-26T18:32:29Z

@compiler-errors You've requested that the fix for #137553 land in a separate PR. However, ironically, the breaking changes are actually required by #137467 and not #137553. Do you think the removal of the now-obsolete maybe_read_scrutinee should happen in a separate PR, or should I do it here so that it also benefits from the crater run?

compiler-errors · 2025-03-26T18:37:30Z

We can crater both together if you think they're not worth separating. I was just trying to accelerate landing the parts that are obviously-not-breaking but it's up to you if you think that effort is worth it or if you're willing to be patient about waiting for the breaking parts (and FCP, etc).

@bors try

ExprUseVisitor: properly report discriminant reads This PR fixes rust-lang#137467. In order to do so, it needs to introduce a small breaking change surrounding the interaction of closure captures with matching against enums with uninhabited variants. Yes – to fix an ICE! ## Background The current upvar inference code handles patterns in two parts: - `ExprUseVisitor::walk_pat` finds the *bindings* being done by the pattern and captures the relevant parts - `ExprUseVisitor::maybe_read_scrutinee` determines whether matching against the pattern will at any point require inspecting a discriminant, and if so, captures *the entire scrutinee*. It also has some weird logic around bindings, deciding to also capture the entire scrutinee if *pretty much any binding exists in the pattern*, with some weird behavior like rust-lang#137553. Nevertheless, something like `|| let (a, _) = x;` will only capture `x.0`, because `maybe_read_scrutinee` does not run for irrefutable patterns at all. This causes issues like rust-lang#137467, where the closure wouldn't be capturing enough, because an irrefutable or-pattern can still require inspecting a discriminant, and the match lowering would then panic, because it couldn't find an appropriate upvar in the closure. My thesis is that this is not a reasonable implementation. To that end, I intend to merge the functionality of both these parts into `walk_pat`, which will bring upvar inference closer to what the MIR lowering actually needs – both in making sure that necessary variables get captured, fixing rust-lang#137467, and in reducing the cases where redundant variables do – fixing rust-lang#137553. This PR introduces the necessary logic into `walk_pat`, fixing rust-lang#137467. A subsequent PR will remove `maybe_read_scrutinee` entirely, which should now be redundant, fixing rust-lang#137553. The latter is still pending, as my current revision doesn't handle opaque types correctly for some reason I haven't looked into yet. ## The breaking change The following example, adapted from the testsuite, compiles on current stable, but will not compile with this PR: ```rust #[derive(Clone, Copy, PartialEq, Eq, Debug)] enum Void {} pub fn main() { let mut r = Result::<Void, (u32, u32)>::Err((0, 0)); let mut f = || { let Err((ref mut a, _)) = r; *a = 1; }; let mut g = || { //~^ ERROR: cannot borrow `r` as mutable more than once at a time let Err((_, ref mut b)) = r; *b = 2; }; f(); g(); assert_eq!(r, Err((1, 2))); } ``` The issue is that, to determine that matching against `Err` here doesn't require inspecting the discriminant, we need to query the `InhabitedPredicate` of the types involved. However, as upvar inference is done during typechecking, the relevant type might not yet be fully inferred. Because of this, performing such a check hits this assertion: https://github.com/rust-lang/rust/blob/43f0014ef0f242418674f49052ed39b70f73bc1c/compiler/rustc_middle/src/ty/inhabitedness/mod.rs#L121 The code used to compile fine, but only because the compiler incorrectly assumed that patterns used within a `let` cannot possibly be inspecting any discriminants. ## Is the breaking change necessary? One other option would be to double down, and introduce a deliberate semantics difference between `let $pat = $expr;` and `match $expr { $pat => ... }`, that syntactically determines whether the pattern is in an irrefutable position, instead of querying the types. **This would not eliminate the breaking change,** but it would limit it to more contrived examples, such as ```rust let ((true, Err((ref mut a, _, _))) | (false, Err((_, ref mut a, _)))) = x; ``` The cost here, would be the complexity added with very little benefit. ## Other notes - I performed various cleanups while working on this. The last commit of the PR is the interesting one. - Due to the temporary duplication of logic between `maybe_read_scrutinee` and `walk_pat`, some of the `#[rustc_capture_analysis]` tests report duplicate messages before deduplication. This is harmless.

bors · 2025-03-26T18:38:42Z

⌛ Trying commit 8ed61e4 with merge 3b30da3...

meithecatte · 2025-03-26T19:42:57Z

We can crater both together if you think they're not worth separating. I was just trying to accelerate landing the parts that are obviously-not-breaking but it's up to you if you think that effort is worth it or if you're willing to be patient about waiting for the breaking parts (and FCP, etc).

That's the thing – one part is a breaking change, the other introduces insta-stable new behavior. There's no easily mergeable part to this.

compiler-errors · 2025-03-26T20:03:52Z

could we give this a less weird pr title pls 💀

@bors try

bors · 2025-03-26T20:05:05Z

⌛ Trying commit 7d5a892 with merge 630b4e8...

ExprUseVisitor: murder maybe_read_scrutinee in cold blood This PR fixes rust-lang#137467. In order to do so, it needs to introduce a small breaking change surrounding the interaction of closure captures with matching against enums with uninhabited variants. Yes – to fix an ICE! ## Background The current upvar inference code handles patterns in two parts: - `ExprUseVisitor::walk_pat` finds the *bindings* being done by the pattern and captures the relevant parts - `ExprUseVisitor::maybe_read_scrutinee` determines whether matching against the pattern will at any point require inspecting a discriminant, and if so, captures *the entire scrutinee*. It also has some weird logic around bindings, deciding to also capture the entire scrutinee if *pretty much any binding exists in the pattern*, with some weird behavior like rust-lang#137553. Nevertheless, something like `|| let (a, _) = x;` will only capture `x.0`, because `maybe_read_scrutinee` does not run for irrefutable patterns at all. This causes issues like rust-lang#137467, where the closure wouldn't be capturing enough, because an irrefutable or-pattern can still require inspecting a discriminant, and the match lowering would then panic, because it couldn't find an appropriate upvar in the closure. My thesis is that this is not a reasonable implementation. To that end, I intend to merge the functionality of both these parts into `walk_pat`, which will bring upvar inference closer to what the MIR lowering actually needs – both in making sure that necessary variables get captured, fixing rust-lang#137467, and in reducing the cases where redundant variables do – fixing rust-lang#137553. This PR introduces the necessary logic into `walk_pat`, fixing rust-lang#137467. A subsequent PR will remove `maybe_read_scrutinee` entirely, which should now be redundant, fixing rust-lang#137553. The latter is still pending, as my current revision doesn't handle opaque types correctly for some reason I haven't looked into yet. ## The breaking change The following example, adapted from the testsuite, compiles on current stable, but will not compile with this PR: ```rust #[derive(Clone, Copy, PartialEq, Eq, Debug)] enum Void {} pub fn main() { let mut r = Result::<Void, (u32, u32)>::Err((0, 0)); let mut f = || { let Err((ref mut a, _)) = r; *a = 1; }; let mut g = || { //~^ ERROR: cannot borrow `r` as mutable more than once at a time let Err((_, ref mut b)) = r; *b = 2; }; f(); g(); assert_eq!(r, Err((1, 2))); } ``` The issue is that, to determine that matching against `Err` here doesn't require inspecting the discriminant, we need to query the `InhabitedPredicate` of the types involved. However, as upvar inference is done during typechecking, the relevant type might not yet be fully inferred. Because of this, performing such a check hits this assertion: https://github.com/rust-lang/rust/blob/43f0014ef0f242418674f49052ed39b70f73bc1c/compiler/rustc_middle/src/ty/inhabitedness/mod.rs#L121 The code used to compile fine, but only because the compiler incorrectly assumed that patterns used within a `let` cannot possibly be inspecting any discriminants. ## Is the breaking change necessary? One other option would be to double down, and introduce a deliberate semantics difference between `let $pat = $expr;` and `match $expr { $pat => ... }`, that syntactically determines whether the pattern is in an irrefutable position, instead of querying the types. **This would not eliminate the breaking change,** but it would limit it to more contrived examples, such as ```rust let ((true, Err((ref mut a, _, _))) | (false, Err((_, ref mut a, _)))) = x; ``` The cost here, would be the complexity added with very little benefit. ## Other notes - I performed various cleanups while working on this. The last commit of the PR is the interesting one. - Due to the temporary duplication of logic between `maybe_read_scrutinee` and `walk_pat`, some of the `#[rustc_capture_analysis]` tests report duplicate messages before deduplication. This is harmless.

meithecatte · 2025-03-26T20:11:42Z

could we give this a less weird pr title pls 💀

Sure thing. I also updated the PR description to describe both changes. I want to add a section on what exactly the insta-stable behavior will be, but I realized that I haven't added a test for that. Should I hold off on pushing that to not break the bors try and crater?

compiler-errors · 2025-03-26T20:13:04Z

Once bors is done with the try build then you can push, no need to wait until crater is done.

As Nadrieril remarked, the previous comment was misleadingly framed.

See clippy issue 16086 for context

rustbot · 2025-12-17T21:12:55Z

rust-analyzer is developed in its own repository. If possible, consider making this change to rust-lang/rust-analyzer instead.

cc @rust-lang/rust-analyzer

rustbot · 2025-12-17T21:12:59Z

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

meithecatte · 2025-12-17T21:19:21Z

Commented out the rust-analyzer tests as per rust-lang/rust-analyzer#21274. Also rebased the branch again, so the CI on the PR branch should run the rust-analyzer tests as well (turns out the CI changes to start testing rust-analyzer on rustc CI landed exactly one day after I last rebased :P).

ChayimFriedman2

LGTM for the rust-analyzer changes

View changes since this review

traviscross · 2025-12-18T03:29:22Z

@bors r=Nadrieril,traviscross,ChayimFriedman2

bors · 2025-12-18T03:29:25Z

📌 Commit 011c5ed has been approved by Nadrieril,traviscross,ChayimFriedman2

It is now in the queue for this repository.

Zalathar · 2025-12-18T03:48:53Z

I was thinking about rolling this up, but in this case rollup=never is probably more prudent.

@bors rollup=never

bors · 2025-12-18T03:54:52Z

⌛ Testing commit 011c5ed with merge ed0006a...

bors · 2025-12-18T07:05:27Z

☀️ Test successful - checks-actions
Approved by: Nadrieril,traviscross,ChayimFriedman2
Pushing ed0006a to main...

github-actions · 2025-12-18T07:08:41Z

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 686f9ce (parent) -> ed0006a (this PR)

Test differences

Show 77 test diffs

Stage 1

[crashes] tests/crashes/119786-1.rs: [missing] -> pass (J1)
[crashes] tests/crashes/119786-2.rs: [missing] -> pass (J1)
[crashes] tests/crashes/119786-3.rs: [missing] -> pass (J1)
[crashes] tests/crashes/119786.rs: pass -> [missing] (J1)
[crashes] tests/crashes/137467-1.rs: pass -> [missing] (J1)
[crashes] tests/crashes/137467-2.rs: pass -> [missing] (J1)
[crashes] tests/crashes/137467-3.rs: pass -> [missing] (J1)
[crashes] tests/crashes/140011.rs: pass -> [missing] (J1)
[ui] tests/ui/closures/2229_closure_analysis/deref-mut-in-pattern.rs: [missing] -> pass (J1)
[ui] tests/ui/closures/2229_closure_analysis/only-inhabited-variant-stable.rs: [missing] -> pass (J1)
[ui] tests/ui/closures/2229_closure_analysis/only-inhabited-variant.rs#exhaustive_patterns: [missing] -> pass (J1)
[ui] tests/ui/closures/2229_closure_analysis/only-inhabited-variant.rs#normal: [missing] -> pass (J1)
[ui] tests/ui/closures/2229_closure_analysis/run_pass/multivariant.rs#exhaustive_patterns: pass -> [missing] (J1)
[ui] tests/ui/closures/2229_closure_analysis/run_pass/multivariant.rs#normal: pass -> [missing] (J1)
[ui] tests/ui/closures/at-pattern-weirdness-issue-137553.rs: [missing] -> pass (J1)
[ui] tests/ui/closures/malformed-pattern-issue-140011.rs: [missing] -> pass (J1)
[ui] tests/ui/closures/or-patterns-issue-137467.rs: [missing] -> pass (J1)

Stage 2

[ui] tests/ui/closures/2229_closure_analysis/deref-mut-in-pattern.rs: [missing] -> pass (J0)
[ui] tests/ui/closures/2229_closure_analysis/only-inhabited-variant-stable.rs: [missing] -> pass (J0)
[ui] tests/ui/closures/2229_closure_analysis/only-inhabited-variant.rs#exhaustive_patterns: [missing] -> pass (J0)
[ui] tests/ui/closures/2229_closure_analysis/only-inhabited-variant.rs#normal: [missing] -> pass (J0)
[ui] tests/ui/closures/2229_closure_analysis/run_pass/multivariant.rs#exhaustive_patterns: pass -> [missing] (J0)
[ui] tests/ui/closures/2229_closure_analysis/run_pass/multivariant.rs#normal: pass -> [missing] (J0)
[ui] tests/ui/closures/at-pattern-weirdness-issue-137553.rs: [missing] -> pass (J0)
[ui] tests/ui/closures/malformed-pattern-issue-140011.rs: [missing] -> pass (J0)
[ui] tests/ui/closures/or-patterns-issue-137467.rs: [missing] -> pass (J0)
[crashes] tests/crashes/119786-1.rs: [missing] -> pass (J2)
[crashes] tests/crashes/119786-2.rs: [missing] -> pass (J2)
[crashes] tests/crashes/119786-3.rs: [missing] -> pass (J2)
[crashes] tests/crashes/119786.rs: pass -> [missing] (J2)
[crashes] tests/crashes/137467-1.rs: pass -> [missing] (J2)
[crashes] tests/crashes/137467-2.rs: pass -> [missing] (J2)
[crashes] tests/crashes/137467-3.rs: pass -> [missing] (J2)
[crashes] tests/crashes/140011.rs: pass -> [missing] (J2)

Additionally, 43 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 ed0006a7ba2dc8fabab8ea94d6f843886311b3c7 --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: 3287.8s -> 4003.6s (+21.8%)
dist-aarch64-llvm-mingw: 6522.1s -> 5583.5s (-14.4%)
aarch64-gnu-llvm-20-2: 3340.6s -> 2864.3s (-14.3%)
aarch64-apple: 11875.1s -> 10281.5s (-13.4%)
pr-check-2: 2547.5s -> 2207.2s (-13.4%)
dist-aarch64-apple: 6929.4s -> 7647.5s (+10.4%)
x86_64-gnu-gcc: 3434.7s -> 3079.9s (-10.3%)
dist-i686-mingw: 10556.4s -> 9508.9s (-9.9%)
aarch64-gnu-llvm-20-1: 3794.5s -> 3432.1s (-9.6%)
tidy: 157.9s -> 172.6s (+9.3%)

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-12-18T07:47:24Z

Finished benchmarking commit (ed0006a): comparison URL.

Overall result: no relevant changes - no action needed

@rustbot label: -perf-regression

Instruction count

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

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: 481.939s -> 481.444s (-0.10%)
Artifact size: 390.59 MiB -> 390.60 MiB (0.01%)

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 Mar 26, 2025

This comment has been minimized.

Sign in to view

meithecatte force-pushed the expr-use-visitor branch from 6b31250 to 4b7bf58 Compare March 26, 2025 15:33

This comment has been minimized.

Sign in to view

meithecatte force-pushed the expr-use-visitor branch 2 times, most recently from c225f17 to ce47a4c Compare March 26, 2025 16:21

This comment has been minimized.

Sign in to view

meithecatte force-pushed the expr-use-visitor branch from ce47a4c to 75afceb Compare March 26, 2025 16:57

meithecatte changed the title ~~[WIP] ExprUseVisitor: properly report discriminant reads~~ ExprUseVisitor: properly report discriminant reads Mar 26, 2025

meithecatte marked this pull request as ready for review March 26, 2025 17:28

rustbot assigned Nadrieril Mar 26, 2025

meithecatte force-pushed the expr-use-visitor branch from 75afceb to 8ed61e4 Compare March 26, 2025 17:36

jieyouxu added the needs-crater This change needs a crater run to check for possible breakage in the ecosystem. label Mar 26, 2025

meithecatte changed the title ~~ExprUseVisitor: properly report discriminant reads~~ ExprUseVisitor: murder maybe_read_scrutinee in cold blood Mar 26, 2025

meithecatte changed the title ~~ExprUseVisitor: murder maybe_read_scrutinee in cold blood~~ ExprUseVisitor: get rid of maybe_read_scrutinee Mar 26, 2025

This comment has been minimized.

Sign in to view

meithecatte and others added 12 commits December 17, 2025 20:47

Add miri tests for new closure capture behavior

19f6bc4

add a comment: MatchPair and ExprUseVisitor must stay in sync

e6c5999

Mark crash 140011 as fixed

3d5d1d7

ExprUseVisitor: resolve a FIXME – it's fine as is

a2e249c

Bless miri tests

4f7915b

Add a test for deref projections in new pattern capture behavior

d05b1d7

Rewrite the comment on is_multivariant_adt

2443fba

As Nadrieril remarked, the previous comment was misleadingly framed.

Add more variations from the PR thread

ae19274

re-bless miri tests

9e98885

search_is_some: move to nursery

de65837

See clippy issue 16086 for context

Re-bless tests

55bbe05

Skip rust-analyzer closure layout tests for now

011c5ed

meithecatte force-pushed the expr-use-visitor branch from 7a7d683 to 011c5ed Compare December 17, 2025 21:12

rustbot added the T-rust-analyzer Relevant to the rust-analyzer team, which will review and decide on the PR/issue. label Dec 17, 2025

ChayimFriedman2 approved these changes Dec 17, 2025

View reviewed changes

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 Dec 18, 2025

bors added the merged-by-bors This PR was explicitly merged by bors. label Dec 18, 2025

bors merged commit ed0006a into rust-lang:main Dec 18, 2025
12 checks passed

rustbot added this to the 1.94.0 milestone Dec 18, 2025

Uh oh!

Make closure capturing have consistent and correct behaviour around patterns #138961

Make closure capturing have consistent and correct behaviour around patterns #138961

Conversation

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

Uh oh!

Background

The breaking change

Is the breaking change necessary?

The new insta-stable behavior

The second, more practically-relevant breaking change

Implementation notes

Uh oh!

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

rustbot commented Mar 26, 2025

Uh oh!

meithecatte commented Mar 26, 2025

Uh oh!

rustbot commented Mar 26, 2025

Uh oh!

meithecatte commented Mar 26, 2025

Uh oh!

compiler-errors commented Mar 26, 2025

Uh oh!

bors commented Mar 26, 2025

Uh oh!

meithecatte commented Mar 26, 2025

Uh oh!

compiler-errors commented Mar 26, 2025

Uh oh!

bors commented Mar 26, 2025

Uh oh!

meithecatte commented Mar 26, 2025

Uh oh!

compiler-errors commented Mar 26, 2025

Uh oh!

This comment has been minimized.

rustbot commented Dec 17, 2025

Uh oh!

rustbot commented Dec 17, 2025

Uh oh!

meithecatte commented Dec 17, 2025

Uh oh!

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

Uh oh!

Choose a reason for hiding this comment

Uh oh!

traviscross commented Dec 18, 2025

Uh oh!

bors commented Dec 18, 2025

Uh oh!

Zalathar commented Dec 18, 2025

Uh oh!

bors commented Dec 18, 2025

Uh oh!

bors commented Dec 18, 2025

Uh oh!

Uh oh!

github-actions bot commented Dec 18, 2025

Test differences

Stage 1

Stage 2

Job duration changes

Uh oh!

rust-timer commented Dec 18, 2025

Overall result: no relevant changes - no action needed

Instruction count

Max RSS (memory usage)

Cycles

Binary size

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

meithecatte commented Mar 26, 2025 •

edited

Loading

ChayimFriedman2 left a comment •

edited by rustbot

Loading