fix: fix the capture behavior of if let in closures

[Embers-of-the-Fire]

Closes #153982.
TL;DR This patch adds the missing capture behavior change for if let statements introduced in RFC 2229.

This patch converts

self.walk_local(init, pat, None, || self.borrow_expr(init, BorrowKind::Immutable))?;

into

self.walk_local(init, pat, None, || Ok(()))?;

so that if let now behaves like let.

[rustbot]

r? @mati865

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

Why was this reviewer chosen?

The reviewer was selected based on:

• Owners of files modified in this PR: compiler
• compiler expanded to 69 candidates
• Random selection from 13 candidates

[meithecatte]

Could you add a test case that's a bit more like #153982, so that there's also a field that doesn't get captured in the first place?

[Kivooeo]

cc @Nadrieril

[meithecatte]

So, this is technically a breaking change, much like #138961, right? It'd be nice to have a proof-of-concept test on which the borrow checker will start erroring, at which point we'd probably wanna do a crater run...

View changes since this review

[meithecatte]

AFAICS, following this change, the f parameter of walk_local will become entirely unused – could you remove it?

[Embers-of-the-Fire]

4d78fd1#diff-945cde608e29cea98a59d63e87bcac74d84a2390a1cfa71b1c89d08007789850L625-L632

[Kivooeo]

@bors try

[rust-bors]

☀️ Try build successful (CI)
Build commit: dec9417 (dec9417b8611e34e787a3e4c37686b5131f9e5c5, parent: 562dee4820c458d823175268e41601d4c060588a)

[Kivooeo]

I'm wondering which mode we should run crater in. Would cargo check be sufficient, or should we use build or build and test instead?

[Embers-of-the-Fire]

Would cargo check be sufficient

AFAIK check should be sufficient since this patch modifies something rather high in the compiler, and in theory, strong dependencies on the size of closures shouldn't be very common. The most likely result is that we may break the unit tests for some of the lower level libraries, but it’s unlikely that this will affect functionality.

[meithecatte]

Since this PR changes the drop order in some cases, it is technically conceivable that some code would have an observable change in behavior after this PR gets merged. It is also technically possible that a crate's test suite would notice this. I would however be extremely surprised if someone has written such code and made a test suite good enough to be able to detect this – previous experience with crater runs for similar adjustments confirms this.

If it was my call to make, I'd run a check run and assume that in the exceedingly unlikely case where someone does depend on this, it'll get caught by the full crater run for the beta.

But my call to make it is not.

[theemathas]

It can technically change run time behavior by changing drop order. I think that's kind of unlikely to be relied on though.

[Kivooeo]

Based on the discussion above, I'm going with just check.

@craterbot run mode=check-only

[craterbot]

👌 Experiment pr-154210 created and queued.
🤖 Automatically detected try build dec9417
⚠️ Try build based on commit 66777ad, but latest commit is 4d78fd1. Did you forget to make a new try build?
🔍 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