Fix drop handling for `if let` expressions #88572

matthewjasper · 2021-09-01T21:55:28Z

MIR lowering for if let expressions is now more complicated now that
if let exists in HIR. This PR adds a scope for the variables bound in
an if let expression and then uses an approach similar to how we
handle loops to ensure that we reliably drop the correct variables.

Closes #88307
cc @flip1995 @richkadel @c410-f3r

rust-highfive · 2021-09-01T21:55:31Z

r? @michaelwoerister

(rust-highfive has picked a reviewer for you, use r? to override)

compiler/rustc_mir_build/src/build/matches/mod.rs

MIR lowering for `if let` expressions is now more complicated now that `if let` exists in HIR. This PR adds a scope for the variables bound in an `if let` expression and then uses an approach similar to how we handle loops to ensure that we reliably drop the correct variables.

c410-f3r

Yeap, changes are not trivial.

Thank you very much, @matthewjasper!

c410-f3r · 2021-09-02T00:02:17Z

compiler/rustc_hir/src/hir.rs

@@ -1187,6 +1187,7 @@ pub struct Arm<'hir> {
 #[derive(Debug, HashStable_Generic)]
 pub enum Guard<'hir> {
    If(&'hir Expr<'hir>),
+    // FIXME use ExprKind::Let for this.


I guess I can take care of this in a following PR

matthewjasper · 2021-09-02T21:18:43Z

r? @oli-obk

oli-obk · 2021-09-03T12:21:36Z

src/test/mir-opt/funky_arms.float_to_exponential_common.ConstProp.diff

@@ -134,7 +135,6 @@
      }

      bb10: {
-          StorageDead(_10);                // scope 2 at $DIR/funky_arms.rs:29:5: 29:6


oli-obk · 2021-09-03T12:28:38Z

...r-opt/match_arm_scopes.complicated_match.SimplifyCfg-initial.after-ElaborateDrops.after.diff

@@ -101,14 +101,13 @@
 -     bb10: {
 +     bb7: {
          _9 = (*_6);                      // scope 0 at $DIR/match-arm-scopes.rs:15:70: 15:71
-          StorageDead(_10);                // scope 0 at $DIR/match-arm-scopes.rs:15:72: 15:73


This diff shows quite a few less-well-placed StorageDead markers.

oli-obk · 2021-09-03T12:40:08Z

Thanks for the thorough documentation/comments, that made reviewing so much easier!

@bors r+ p=1 (regression fix, should get merged before beta branch off, we really don't want to backport this)

bors · 2021-09-03T12:40:09Z

📌 Commit 9366dfd has been approved by oli-obk

bors · 2021-09-03T14:23:26Z

⌛ Testing commit 9366dfd with merge 304ba69ef66cbeb06bc69816f85d5e69f6115f3c...

bors · 2021-09-03T14:47:08Z

💔 Test failed - checks-actions

oli-obk · 2021-09-03T15:03:47Z

ugh yea, the instrument coverage mir opt test requires you to locally enable instrumentation in config.toml, which may require some additional setup to get working

oli-obk · 2021-09-03T15:03:54Z

r=me with that

richkadel · 2021-09-03T15:09:43Z

@matthewjasper you may need to enable profiler = true and re-bless the mir-opt.

Hopefully this isn't throwing off coverage ranges in run-make-fulldeps/coverage, but you make want to test that locally as well.

Thanks!

richkadel · 2021-09-03T15:11:34Z

Honestly, I think that setting should be the default now.

richkadel · 2021-09-03T18:59:53Z

src/test/run-make-fulldeps/coverage-reports/expected_show_coverage.uses_inline_crate.txt

  |   39|      1|pub fn used_only_from_bin_crate_generic_function<T: Debug>(arg: T) {
  |   40|      1|    println!("used_only_from_bin_crate_generic_function with {:?}", arg);
  |   41|      1|}
  ------------------
-  | used_inline_crate::used_only_from_bin_crate_generic_function::<&str>:
+  | used_inline_crate::used_only_from_bin_crate_generic_function::<&alloc::vec::Vec<i32>>:


These differences in coverage results are OK (you can keep them in your commit, or drop them).

Unfortunately, llvm-cov show reports have some non-deterministic ordering. The rust tests ignore those kinds of diffs.

matthewjasper · 2021-09-03T19:35:57Z

@bors r=oli-obk

bors · 2021-09-03T19:35:58Z

📌 Commit 4e2fd4f has been approved by oli-obk

bors · 2021-09-03T20:31:51Z

⌛ Testing commit 4e2fd4f with merge b7404c8...

bors · 2021-09-03T23:12:30Z

☀️ Test successful - checks-actions
Approved by: oli-obk
Pushing b7404c8 to master...

…shtriplett Stabilize `let_chains` in Rust 1.64 # Stabilization proposal This PR proposes the stabilization of `#![feature(let_chains)]` in a future-compatibility way that will allow the **possible** addition of the `EXPR is PAT` syntax. Tracking issue: rust-lang#53667 Version: 1.64 (beta => 2022-08-11, stable => 2022-10-22). ## What is stabilized The ability to chain let expressions along side local variable declarations or ordinary conditional expressions. For example: ```rust pub enum Color { Blue, Red, Violet, } pub enum Flower { Rose, Tulip, Violet, } pub fn roses_are_red_violets_are_blue_printer( (first_flower, first_flower_color): (Flower, Color), (second_flower, second_flower_color): (Flower, Color), pick_up_lines: &[&str], ) { if let Flower::Rose = first_flower && let Color::Red = first_flower_color && let Flower::Violet = second_flower && let Color::Blue = second_flower_color && let &[first_pick_up_line, ..] = pick_up_lines { println!("Roses are red, violets are blue, {}", first_pick_up_line); } } fn main() { roses_are_red_violets_are_blue_printer( (Flower::Rose, Color::Red), (Flower::Violet, Color::Blue), &["sugar is sweet and so are you"], ); } ``` ## Motivation The main motivation for this feature is improving readability, ergonomics and reducing paper cuts. For more examples, see the [RFC](https://github.com/rust-lang/rfcs/blob/master/text/2497-if-let-chains.md). ## What isn't stabilized * Let chains in match guards (`if_let_guard`) * Resolution of divergent non-terminal matchers * The `EXPR is PAT` syntax ## History * On 2017-12-24, [RFC: if- and while-let-chains](rust-lang/rfcs#2260) * On 2018-07-12, [eRFC: if- and while-let-chains, take 2](rust-lang/rfcs#2497) * On 2018-08-24, [Tracking issue for eRFC 2497, "if- and while-let-chains, take 2](rust-lang#53667) * On 2019-03-19, [Run branch cleanup after copy prop](rust-lang#59290) * On 2019-03-26, [Generalize diagnostic for x = y where bool is the expected type](rust-lang#59439) * On 2019-04-24, [Introduce hir::ExprKind::Use and employ in for loop desugaring](rust-lang#60225) * On 2019-03-19, [[let_chains, 1/6] Remove hir::ExprKind::If](rust-lang#59288) * On 2019-05-15, [[let_chains, 2/6] Introduce Let(..) in AST, remove IfLet + WhileLet and parse let chains](rust-lang#60861) * On 2019-06-20, [[let_chains, 3/6] And then there was only Loop](rust-lang#61988) * On 2020-11-22, [Reintroduce hir::ExprKind::If](rust-lang#79328) * On 2020-12-24, [Introduce hir::ExprKind::Let - Take 2](rust-lang#80357) * On 2021-02-19, [Lower condition of if expression before it's "then" block](rust-lang#82308) * On 2021-09-01, [Fix drop handling for `if let` expressions](rust-lang#88572) * On 2021-09-04, [Formally implement let chains](rust-lang#88642) * On 2022-01-19, [Add tests to ensure that let_chains works with if_let_guard](rust-lang#93086) * On 2022-01-18, [Introduce `enhanced_binary_op` feature](rust-lang#93049) * On 2022-01-22, [Fix `let_chains` and `if_let_guard` feature flags](rust-lang#93213) * On 2022-02-25, [Initiate the inner usage of `let_chains`](rust-lang#94376) * On 2022-01-28, [[WIP] Introduce ast::StmtKind::LetElse to allow the usage of `let_else` with `let_chains`](rust-lang#93437) * On 2022-02-26, [1 - Make more use of `let_chains`](rust-lang#94396) * On 2022-02-26, [2 - Make more use of `let_chains`](rust-lang#94400) * On 2022-02-27, [3 - Make more use of `let_chains`](rust-lang#94420) * On 2022-02-28, [4 - Make more use of `let_chains`](rust-lang#94445) * On 2022-02-28, [5 - Make more use of `let_chains`](rust-lang#94448) * On 2022-02-28, [6 - Make more use of `let_chains`](rust-lang#94465) * On 2022-03-01, [7 - Make more use of `let_chains`](rust-lang#94476) * On 2022-03-01, [8 - Make more use of `let_chains`](rust-lang#94484) * On 2022-03-01, [9 - Make more use of `let_chains`](rust-lang#94498) * On 2022-03-08, [Warn users about `||` in let chain expressions](rust-lang#94754) From the first RFC (2017-12-24) to the theoretical future stabilization day (2022-10-22), it can be said that this feature took 4 years, 9 months and 28 days of research, development, discussions, agreements and headaches to be settled. ## Divergent non-terminal matchers More specifically, rust-lang#86730. ```rust macro_rules! mac { ($e:expr) => { if $e { true } else { false } }; } fn main() { // OK! assert_eq!(mac!(true && let 1 = 1), true); // ERROR! Anything starting with `let` is not considered an expression assert_eq!(mac!(let 1 = 1 && true), true); } ``` To the best of my knowledge, such error or divergence is orthogonal, does not prevent stabilization and can be tackled independently in the near future or effectively in the next Rust 2024 edition. If not, then https://github.com/c410-f3r/rust/tree/let-macro-blah contains a set of changes that will consider `let` an expression. It is possible that none of the solutions above satisfies all applicable constraints but I personally don't know of any other plausible answers. ## Alternative syntax Taking into account the usefulness of this feature and the overwhelming desire to use both now and in the past, `let PAT = EXPR` will be utilized for stabilization but it doesn't or shall create any obstacle for a **possible** future addition of `EXPR is PAT`. The introductory snippet would then be written as the following. ```rust if first_flower is Flower::Rose && first_flower_color is Color::Red && second_flower is Flower::Violet && second_flower_color is Color::Blue && pick_up_lines is &[first_pick_up_line, ..] { println!("Roses are red, violets are blue, {}", first_pick_up_line); } ``` Just to reinforce, this PR only unblocks a **possible** future road for `EXPR is PAT` and does emphasize what is better or what is worse. ## Tests * [Verifies the drop order of let chains and ensures it won't change in the future in an unpredictable way](https://github.com/rust-lang/rust/blob/master/src/test/ui/mir/mir_let_chains_drop_order.rs) * [AST lowering does not wrap let chains in an `DropTemps` expression](https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2497-if-let-chains/ast-lowering-does-not-wrap-let-chains.rs) * [Checks pretty printing output](https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2497-if-let-chains/ast-pretty-check.rs) * [Verifies uninitialized variables due to MIR modifications](https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2497-if-let-chains/chains-without-let.rs) * [A collection of statements where `let` expressions are forbidden](https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2497-if-let-chains/disallowed-positions.rs) * [All or at least most of the places where let chains are allowed](https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2497-if-let-chains/feature-gate.rs) * [Ensures that irrefutable lets are allowed in let chains](https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2497-if-let-chains/irrefutable-lets.rs) * [issue-88498.rs](https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2497-if-let-chains/issue-88498.rs), [issue-90722.rs](https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2497-if-let-chains/issue-90722.rs), [issue-92145.rs](https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2497-if-let-chains/issue-92145.rs) and [issue-93150.rs](https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2497-if-let-chains/issue-93150.rs) were bugs found by third parties and fixed overtime. * [Indexing was triggering a ICE due to a wrongly constructed MIR graph](https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2497-if-let-chains/no-double-assigments.rs) * [Protects the precedence of `&&` in relation to other things](https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2497-if-let-chains/protect-precedences.rs) * [`let_chains`, as well as `if_let_guard`, has a valid MIR graph that evaluates conditional expressions correctly](https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2497-if-let-chains/then-else-blocks.rs) Most of the infra-structure used by let chains is also used by `if` expressions in stable compiler versions since rust-lang#80357 and rust-lang#88572. As a result, no bugs were found since the integration of rust-lang#88642. ## Possible future work * Let chains in match guards is implemented and working but stabilization is blocked by `if_let_guard`. * The usage of `let_chains` with `let_else` is possible but not implemented. Regardless, one attempt was introduced and closed in rust-lang#93437. Thanks `@Centril` for creating the RFC and huge thanks (again) to `@matthewjasper` for all the reviews, mentoring and MIR implementations. Fixes rust-lang#53667

Stabilize `let_chains` in Rust 1.64 # Stabilization proposal This PR proposes the stabilization of `#![feature(let_chains)]` in a future-compatibility way that will allow the **possible** addition of the `EXPR is PAT` syntax. Tracking issue: #53667 Version: 1.64 (beta => 2022-08-11, stable => 2022-10-22). ## What is stabilized The ability to chain let expressions along side local variable declarations or ordinary conditional expressions. For example: ```rust pub enum Color { Blue, Red, Violet, } pub enum Flower { Rose, Tulip, Violet, } pub fn roses_are_red_violets_are_blue_printer( (first_flower, first_flower_color): (Flower, Color), (second_flower, second_flower_color): (Flower, Color), pick_up_lines: &[&str], ) { if let Flower::Rose = first_flower && let Color::Red = first_flower_color && let Flower::Violet = second_flower && let Color::Blue = second_flower_color && let &[first_pick_up_line, ..] = pick_up_lines { println!("Roses are red, violets are blue, {}", first_pick_up_line); } } fn main() { roses_are_red_violets_are_blue_printer( (Flower::Rose, Color::Red), (Flower::Violet, Color::Blue), &["sugar is sweet and so are you"], ); } ``` ## Motivation The main motivation for this feature is improving readability, ergonomics and reducing paper cuts. For more examples, see the [RFC](https://github.com/rust-lang/rfcs/blob/master/text/2497-if-let-chains.md). ## What isn't stabilized * Let chains in match guards (`if_let_guard`) * Resolution of divergent non-terminal matchers * The `EXPR is PAT` syntax ## History * On 2017-12-24, [RFC: if- and while-let-chains](rust-lang/rfcs#2260) * On 2018-07-12, [eRFC: if- and while-let-chains, take 2](rust-lang/rfcs#2497) * On 2018-08-24, [Tracking issue for eRFC 2497, "if- and while-let-chains, take 2](rust-lang/rust#53667) * On 2019-03-19, [Run branch cleanup after copy prop](rust-lang/rust#59290) * On 2019-03-26, [Generalize diagnostic for x = y where bool is the expected type](rust-lang/rust#59439) * On 2019-04-24, [Introduce hir::ExprKind::Use and employ in for loop desugaring](rust-lang/rust#60225) * On 2019-03-19, [[let_chains, 1/6] Remove hir::ExprKind::If](rust-lang/rust#59288) * On 2019-05-15, [[let_chains, 2/6] Introduce Let(..) in AST, remove IfLet + WhileLet and parse let chains](rust-lang/rust#60861) * On 2019-06-20, [[let_chains, 3/6] And then there was only Loop](rust-lang/rust#61988) * On 2020-11-22, [Reintroduce hir::ExprKind::If](rust-lang/rust#79328) * On 2020-12-24, [Introduce hir::ExprKind::Let - Take 2](rust-lang/rust#80357) * On 2021-02-19, [Lower condition of if expression before it's "then" block](rust-lang/rust#82308) * On 2021-09-01, [Fix drop handling for `if let` expressions](rust-lang/rust#88572) * On 2021-09-04, [Formally implement let chains](rust-lang/rust#88642) * On 2022-01-19, [Add tests to ensure that let_chains works with if_let_guard](rust-lang/rust#93086) * On 2022-01-18, [Introduce `enhanced_binary_op` feature](rust-lang/rust#93049) * On 2022-01-22, [Fix `let_chains` and `if_let_guard` feature flags](rust-lang/rust#93213) * On 2022-02-25, [Initiate the inner usage of `let_chains`](rust-lang/rust#94376) * On 2022-01-28, [[WIP] Introduce ast::StmtKind::LetElse to allow the usage of `let_else` with `let_chains`](rust-lang/rust#93437) * On 2022-02-26, [1 - Make more use of `let_chains`](rust-lang/rust#94396) * On 2022-02-26, [2 - Make more use of `let_chains`](rust-lang/rust#94400) * On 2022-02-27, [3 - Make more use of `let_chains`](rust-lang/rust#94420) * On 2022-02-28, [4 - Make more use of `let_chains`](rust-lang/rust#94445) * On 2022-02-28, [5 - Make more use of `let_chains`](rust-lang/rust#94448) * On 2022-02-28, [6 - Make more use of `let_chains`](rust-lang/rust#94465) * On 2022-03-01, [7 - Make more use of `let_chains`](rust-lang/rust#94476) * On 2022-03-01, [8 - Make more use of `let_chains`](rust-lang/rust#94484) * On 2022-03-01, [9 - Make more use of `let_chains`](rust-lang/rust#94498) * On 2022-03-08, [Warn users about `||` in let chain expressions](rust-lang/rust#94754) From the first RFC (2017-12-24) to the theoretical future stabilization day (2022-10-22), it can be said that this feature took 4 years, 9 months and 28 days of research, development, discussions, agreements and headaches to be settled. ## Divergent non-terminal matchers More specifically, rust-lang/rust#86730. ```rust macro_rules! mac { ($e:expr) => { if $e { true } else { false } }; } fn main() { // OK! assert_eq!(mac!(true && let 1 = 1), true); // ERROR! Anything starting with `let` is not considered an expression assert_eq!(mac!(let 1 = 1 && true), true); } ``` To the best of my knowledge, such error or divergence is orthogonal, does not prevent stabilization and can be tackled independently in the near future or effectively in the next Rust 2024 edition. If not, then https://github.com/c410-f3r/rust/tree/let-macro-blah contains a set of changes that will consider `let` an expression. It is possible that none of the solutions above satisfies all applicable constraints but I personally don't know of any other plausible answers. ## Alternative syntax Taking into account the usefulness of this feature and the overwhelming desire to use both now and in the past, `let PAT = EXPR` will be utilized for stabilization but it doesn't or shall create any obstacle for a **possible** future addition of `EXPR is PAT`. The introductory snippet would then be written as the following. ```rust if first_flower is Flower::Rose && first_flower_color is Color::Red && second_flower is Flower::Violet && second_flower_color is Color::Blue && pick_up_lines is &[first_pick_up_line, ..] { println!("Roses are red, violets are blue, {}", first_pick_up_line); } ``` Just to reinforce, this PR only unblocks a **possible** future road for `EXPR is PAT` and does emphasize what is better or what is worse. ## Tests * [Verifies the drop order of let chains and ensures it won't change in the future in an unpredictable way](https://github.com/rust-lang/rust/blob/master/src/test/ui/mir/mir_let_chains_drop_order.rs) * [AST lowering does not wrap let chains in an `DropTemps` expression](https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2497-if-let-chains/ast-lowering-does-not-wrap-let-chains.rs) * [Checks pretty printing output](https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2497-if-let-chains/ast-pretty-check.rs) * [Verifies uninitialized variables due to MIR modifications](https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2497-if-let-chains/chains-without-let.rs) * [A collection of statements where `let` expressions are forbidden](https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2497-if-let-chains/disallowed-positions.rs) * [All or at least most of the places where let chains are allowed](https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2497-if-let-chains/feature-gate.rs) * [Ensures that irrefutable lets are allowed in let chains](https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2497-if-let-chains/irrefutable-lets.rs) * [issue-88498.rs](https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2497-if-let-chains/issue-88498.rs), [issue-90722.rs](https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2497-if-let-chains/issue-90722.rs), [issue-92145.rs](https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2497-if-let-chains/issue-92145.rs) and [issue-93150.rs](https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2497-if-let-chains/issue-93150.rs) were bugs found by third parties and fixed overtime. * [Indexing was triggering a ICE due to a wrongly constructed MIR graph](https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2497-if-let-chains/no-double-assigments.rs) * [Protects the precedence of `&&` in relation to other things](https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2497-if-let-chains/protect-precedences.rs) * [`let_chains`, as well as `if_let_guard`, has a valid MIR graph that evaluates conditional expressions correctly](https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2497-if-let-chains/then-else-blocks.rs) Most of the infra-structure used by let chains is also used by `if` expressions in stable compiler versions since rust-lang/rust#80357 and rust-lang/rust#88572. As a result, no bugs were found since the integration of rust-lang/rust#88642. ## Possible future work * Let chains in match guards is implemented and working but stabilization is blocked by `if_let_guard`. * The usage of `let_chains` with `let_else` is possible but not implemented. Regardless, one attempt was introduced and closed in rust-lang/rust#93437. Thanks `@Centril` for creating the RFC and huge thanks (again) to `@matthewjasper` for all the reviews, mentoring and MIR implementations. Fixes #53667

…jasper Don't pass a break scope to `Builder::break_for_else` This method would previously take a target scope, and then verify that it was equal to the scope on top of the if-then scope stack. In practice, this means that callers have to go out of their way to pass around redundant scope information that's already on the if-then stack. So it's easier to just retrieve the correct scope directly from the if-then stack, and simplify the other code that was passing it around. --- Both ways of indicating the break target were introduced in rust-lang#88572. I haven't been able to find any strong indication of whether this was done deliberately, or whether it was just an implementation artifact. But to me it doesn't seem useful to carefully pass around the same scope in two different ways.

Rollup merge of rust-lang#122137 - Zalathar:if-break-scope, r=matthewjasper Don't pass a break scope to `Builder::break_for_else` This method would previously take a target scope, and then verify that it was equal to the scope on top of the if-then scope stack. In practice, this means that callers have to go out of their way to pass around redundant scope information that's already on the if-then stack. So it's easier to just retrieve the correct scope directly from the if-then stack, and simplify the other code that was passing it around. --- Both ways of indicating the break target were introduced in rust-lang#88572. I haven't been able to find any strong indication of whether this was done deliberately, or whether it was just an implementation artifact. But to me it doesn't seem useful to carefully pass around the same scope in two different ways.

rust-highfive assigned michaelwoerister Sep 1, 2021

rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Sep 1, 2021

camsteffen reviewed Sep 1, 2021

View reviewed changes

compiler/rustc_mir_build/src/build/matches/mod.rs Outdated Show resolved Hide resolved

matthewjasper force-pushed the if-let-scoping-fix branch from 0250fba to ff8c0ef Compare September 1, 2021 22:48

This comment has been minimized.

Sign in to view

c410-f3r reviewed Sep 2, 2021

View reviewed changes

Remove TODO

fd5b40f

This comment has been minimized.

Sign in to view

Bless 32bit MIR opt tests

9366dfd

flip1995 mentioned this pull request Sep 2, 2021

Rustup rust-lang/rust-clippy#7604

Merged

rust-highfive assigned oli-obk and unassigned michaelwoerister Sep 2, 2021

oli-obk reviewed Sep 3, 2021

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 Sep 3, 2021

This comment has been minimized.

Sign in to view

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 Sep 3, 2021

Update coverage tests

4e2fd4f

richkadel approved these changes Sep 3, 2021

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 Sep 3, 2021

m-ou-se added this to the 1.56.0 milestone Sep 3, 2021

bors added the merged-by-bors This PR was explicitly merged by bors. label Sep 3, 2021

bors merged commit b7404c8 into rust-lang:master Sep 3, 2021

matthewjasper deleted the if-let-scoping-fix branch September 3, 2021 23:42

bors mentioned this pull request Sep 3, 2021

Scalar replacement of enums #88628

Closed

This was referenced Sep 4, 2021

StorageLive is added on a local that was already live #88649

Closed

Change scope of temporaries in match guards #88678

Merged

c410-f3r mentioned this pull request Mar 14, 2022

Stabilize let_chains in Rust 1.64 #94927

Merged

Zalathar mentioned this pull request Mar 7, 2024

Don't pass a break scope to Builder::break_for_else #122137

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Fix drop handling for `if let` expressions #88572

Fix drop handling for `if let` expressions #88572

matthewjasper commented Sep 1, 2021

rust-highfive commented Sep 1, 2021

This comment has been minimized.

c410-f3r left a comment

c410-f3r Sep 2, 2021

This comment has been minimized.

matthewjasper commented Sep 2, 2021

oli-obk Sep 3, 2021

oli-obk Sep 3, 2021

oli-obk commented Sep 3, 2021

bors commented Sep 3, 2021

bors commented Sep 3, 2021

This comment has been minimized.

bors commented Sep 3, 2021

oli-obk commented Sep 3, 2021

oli-obk commented Sep 3, 2021

richkadel commented Sep 3, 2021

richkadel commented Sep 3, 2021

richkadel Sep 3, 2021

matthewjasper commented Sep 3, 2021

bors commented Sep 3, 2021

bors commented Sep 3, 2021

bors commented Sep 3, 2021

Fix drop handling for if let expressions #88572

Fix drop handling for if let expressions #88572

Conversation

matthewjasper commented Sep 1, 2021

rust-highfive commented Sep 1, 2021

This comment has been minimized.

c410-f3r left a comment

Choose a reason for hiding this comment

c410-f3r Sep 2, 2021

Choose a reason for hiding this comment

This comment has been minimized.

matthewjasper commented Sep 2, 2021

oli-obk Sep 3, 2021

Choose a reason for hiding this comment

oli-obk Sep 3, 2021

Choose a reason for hiding this comment

oli-obk commented Sep 3, 2021

bors commented Sep 3, 2021

bors commented Sep 3, 2021

This comment has been minimized.

bors commented Sep 3, 2021

oli-obk commented Sep 3, 2021

oli-obk commented Sep 3, 2021

richkadel commented Sep 3, 2021

richkadel commented Sep 3, 2021

richkadel Sep 3, 2021

Choose a reason for hiding this comment

matthewjasper commented Sep 3, 2021

bors commented Sep 3, 2021

bors commented Sep 3, 2021

bors commented Sep 3, 2021

Fix drop handling for `if let` expressions #88572

Fix drop handling for `if let` expressions #88572