[let_chains, 3/6] And then there was only Loop #61988

Centril · 2019-06-20T12:29:17Z

Here we remove hir::ExprKind::While.
Instead, we desugar: 'label: while $cond $body into:

'label: loop {
    match DropTemps($cond) {
        true => $body,
        _ => break,
    }
}

Per #53667 (comment).
This is a follow up to #59288 which did the same for if expressions.

r? @matthewjasper

src/librustc/middle/liveness.rs

matthewjasper · 2019-06-20T19:11:28Z

src/test/incremental/hashes/while_loops.rs

@@ -191,7 +191,7 @@ pub fn change_continue_label() {
 }

 #[cfg(not(cfail1))]
-#[rustc_clean(cfg="cfail2", except="HirBody, mir_built")]
+#[rustc_clean(cfg="cfail2", except="typeck_tables_of, HirBody, mir_built, optimized_mir")]


Hmm, while true isn't being optimized to be the same as loop here. This is probably not blocking since we lint against while true. cc @oli-obk @wesleywiser

So this would be (in HIR terms):

loop { match DropTemps(true) { true => $body, _ => break, } }

which feels like something const-prop should reduce to (ofc it operates on MIR... not HIR..):

loop { match true { true => $body, _ => break, } }

==>

loop { $body }

The typeck_tables_of bits are fixed now at least. The incremental behavior is the same for while and while let loops now which feels at least consistent.

I also agree that it shouldn't be blocking.

src/librustc_lint/builtin.rs

src/librustc_typeck/check/_match.rs

src/librustc_typeck/check/expr.rs

oli-obk · 2019-06-21T06:58:15Z

src/test/ui/consts/const-labeled-break.rs

@@ -4,7 +4,6 @@
 // See https://github.com/rust-lang/rust/issues/51350 for more information.

 const CRASH: () = 'a: while break 'a {};
+//~^ ERROR constant contains unimplemented expression type


ugh, that's a breaking change.

@eddyb what if we did const prop and branch cleanup before const qualif?

Actually, just branch cleanup may suffice here. @Centril what's the MIR of this constant after your changes?

The issue is probably that we now generate a FalseUnwind for while loops now. We could ignore them in const qualification and allow all "loops that can't ever loop" in consts but they have to stay in the MIR until borrow checking.

ugh, that's a breaking change.

That's... debatable. :)

From my perspective this is a bug-fix that fixes the unjustified semantic divergence between loop- and while-expressions. Moreover, before 1.33.0 this was an ICE or error all the way back to 1.0.0. Also, you have to literally write 'label: while break 'label {}. Other forms you might think should behave similarly such as while break {} do not work. I also find it highly unlikely that anyone would ever write 'label: while break 'label {} because it is useless.

I r+ed this test in #60360 because it documented the behavior of the compiler. But now that the behavior is fixed so too should the test.

@eddyb what if we did const prop and branch cleanup before const qualif?

That would make const-prop a part of our stability guarantees. I think that's a non-starter from a T-Lang POV.

We could ignore them in const qualification and allow all "loops that can't ever loop" in consts but they have to stay in the MIR until borrow checking.

We could... but that would allow more behavior that is disallowed now. Also, I think it is not worth any of y'all's time to make 'label: while break 'label {} continue to work.

Wait, so what's the current behavior, ignoring constants, for 'label: while break 'label {}?
Is it a noop, or an error?

A noop, see https://discordapp.com/channels/442252698964721669/443151243398086667/593054967624105997. Still a noop after wrt. dynamic semantics.

@matthewjasper I looked into FalseUnwind and indeed it should've been ignored in const-checking, see #62272.

(Probably doesn't need to hold up this PR, it can be fixed independently).

Centril · 2019-06-23T17:01:18Z

Rebased. Also cleaned up lowering after #60861 so that it is more in line with how If is lowered and so that there's less duplication..

This should be good to go aside from question in #61988 (comment).

Centril · 2019-06-24T02:28:20Z

Fixed the incremental test failure.

matthewjasper · 2019-06-25T21:49:27Z

r=me with the liveness comment updated

Centril · 2019-06-26T16:14:45Z

Rebased, updated the liveness comment, and also "blessed" the mir-opt test to the actual MIR output.

@bors r=matthewjasper rollup=never

bors · 2019-06-26T16:14:46Z

📌 Commit 63dc9a4 has been approved by matthewjasper

…yet.

Centril · 2019-07-06T04:48:00Z

Rebased; @bors r=matthewjasper rollup=never

bors · 2019-07-06T04:48:01Z

📌 Commit 9b1d513 has been approved by matthewjasper

bors · 2019-07-06T06:15:50Z

⌛ Testing commit 9b1d513 with merge 254f201...

@matthewjasper

[let_chains, 3/6] And then there was only Loop Here we remove `hir::ExprKind::While`. Instead, we desugar: `'label: while $cond $body` into: ```rust 'label: loop { match DropTemps($cond) { true => $body, _ => break, } } ``` Per #53667 (comment). This is a follow up to #59288 which did the same for `if` expressions. r? @matthewjasper

bors · 2019-07-06T09:38:10Z

☀️ Test successful - checks-azure, checks-travis, status-appveyor
Approved by: matthewjasper
Pushing 254f201 to master...

Fix breakage due to rust-lang/rust#61988 changelog: none

…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

rust-highfive assigned matthewjasper Jun 20, 2019

rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jun 20, 2019

Centril commented Jun 20, 2019

View reviewed changes

src/librustc/middle/liveness.rs Outdated Show resolved Hide resolved

Centril mentioned this pull request Jun 20, 2019

Clean up MIR drop generation #61872

Merged

This comment has been minimized.

Sign in to view

Centril force-pushed the there-is-only-loop branch from b0b569a to dad7845 Compare June 20, 2019 12:47

matthewjasper reviewed Jun 20, 2019

View reviewed changes

petrochenkov mentioned this pull request Jun 20, 2019

for loop desugaring treats the loop's trailing expression in unusual way #61902

Open

oli-obk reviewed Jun 21, 2019

View reviewed changes

src/librustc_lint/builtin.rs Outdated Show resolved Hide resolved

oli-obk reviewed Jun 21, 2019

View reviewed changes

src/librustc_typeck/check/_match.rs Outdated Show resolved Hide resolved

oli-obk reviewed Jun 21, 2019

View reviewed changes

src/librustc_typeck/check/expr.rs Outdated Show resolved Hide resolved

oli-obk reviewed Jun 21, 2019

View reviewed changes

Centril force-pushed the there-is-only-loop branch from dad7845 to cab21f9 Compare June 21, 2019 23:30

This comment has been minimized.

Sign in to view

Centril force-pushed the there-is-only-loop branch from cab21f9 to 74f6fa3 Compare June 22, 2019 05:37

This comment has been minimized.

Sign in to view

Centril force-pushed the there-is-only-loop branch from 74f6fa3 to 0aeb1d9 Compare June 23, 2019 16:58

This comment has been minimized.

Sign in to view

Centril mentioned this pull request Jun 25, 2019

Cannot assign twice to immutable variable with 'l: while break 'l {} as initializer #62115

Closed

This comment has been minimized.

Sign in to view

Centril force-pushed the there-is-only-loop branch from a5acea6 to 63dc9a4 Compare June 26, 2019 15:44

This comment has been minimized.

Sign in to view

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 Jun 26, 2019

This comment has been minimized.

Sign in to view

Centril added 9 commits July 6, 2019 06:43

while desugars to loop so 'a: while break 'a {} in ctfe doesn't work …

7d1cd41

…yet.

Adjust incremental test while_loops.rs

ebcc966

Make sure while-exprs require 'cond: bool' exactly.

f01562a

Make WhileTrue into an EarlyLintPass lint.

5477354

Lowering: Fuse ExprKind::While logic + Cleanup.

26144fe

while_{let_}loops/change_{break,continue}: typeck_tables_of clean.

b9e7e31

Cleanup liveness comment.

b32beb8

Bless mir-opt/while-storage.rs.

075e381

--bless --compare-mode=nll

9b1d513

Centril force-pushed the there-is-only-loop branch from e724761 to 9b1d513 Compare July 6, 2019 04:46

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-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Jul 6, 2019

matthiaskrgr mentioned this pull request Jul 6, 2019

Update clippy #62434

Merged

bors added the merged-by-bors This PR was explicitly merged by bors. label Jul 6, 2019

bors merged commit 9b1d513 into rust-lang:master Jul 6, 2019

This was referenced Jul 6, 2019

non_ascii_idents lint (part of RFC 2457) #61883

Merged

rustc_mir: follow FalseUnwind's real_target edge in qualify_consts. #62274

Merged

Centril deleted the there-is-only-loop branch July 6, 2019 11:10

Centril mentioned this pull request Jul 6, 2019

Tracking issue for eRFC 2497, "if- and while-let-chains, take 2" #53667

Open

14 tasks

bors added a commit to rust-lang/rust-clippy that referenced this pull request Jul 6, 2019

Auto merge of #4258 - mikerite:fix-breakage-20190706, r=Manishearth

61204dc

Fix breakage due to rust-lang/rust#61988 changelog: none

bors added a commit to rust-lang/rust-clippy that referenced this pull request Jul 7, 2019

Auto merge of #4258 - mikerite:fix-breakage-20190706, r=Manishearth

316da7e

Fix breakage due to rust-lang/rust#61988 changelog: none

Centril added the F-let_chains `#![feature(let_chains)]` label Oct 10, 2019

c410-f3r mentioned this pull request Mar 14, 2022

Stabilize let_chains in Rust 1.64 #94927

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[let_chains, 3/6] And then there was only Loop #61988

[let_chains, 3/6] And then there was only Loop #61988

Centril commented Jun 20, 2019

This comment has been minimized.

matthewjasper Jun 20, 2019

Centril Jun 20, 2019 •

edited

Loading

Centril Jun 24, 2019 •

edited

Loading

oli-obk Jun 21, 2019

matthewjasper Jun 21, 2019

Centril Jun 21, 2019 •

edited

Loading

eddyb Jun 25, 2019

Centril Jun 25, 2019 •

edited

Loading

eddyb Jul 1, 2019 •

edited

Loading

This comment has been minimized.

This comment has been minimized.

Centril commented Jun 23, 2019

This comment has been minimized.

Centril commented Jun 24, 2019

matthewjasper commented Jun 25, 2019

This comment has been minimized.

Centril commented Jun 26, 2019

bors commented Jun 26, 2019

This comment has been minimized.

This comment has been minimized.

Centril commented Jul 6, 2019

bors commented Jul 6, 2019

bors commented Jul 6, 2019

bors commented Jul 6, 2019

[let_chains, 3/6] And then there was only Loop #61988

[let_chains, 3/6] And then there was only Loop #61988

Conversation

Centril commented Jun 20, 2019

This comment has been minimized.

matthewjasper Jun 20, 2019

Choose a reason for hiding this comment

Centril Jun 20, 2019 • edited Loading

Choose a reason for hiding this comment

Centril Jun 24, 2019 • edited Loading

Choose a reason for hiding this comment

oli-obk Jun 21, 2019

Choose a reason for hiding this comment

matthewjasper Jun 21, 2019

Choose a reason for hiding this comment

Centril Jun 21, 2019 • edited Loading

Choose a reason for hiding this comment

eddyb Jun 25, 2019

Choose a reason for hiding this comment

Centril Jun 25, 2019 • edited Loading

Choose a reason for hiding this comment

eddyb Jul 1, 2019 • edited Loading

Choose a reason for hiding this comment

This comment has been minimized.

This comment has been minimized.

Centril commented Jun 23, 2019

This comment has been minimized.

Centril commented Jun 24, 2019

matthewjasper commented Jun 25, 2019

This comment has been minimized.

Centril commented Jun 26, 2019

bors commented Jun 26, 2019

This comment has been minimized.

This comment has been minimized.

Centril commented Jul 6, 2019

bors commented Jul 6, 2019

bors commented Jul 6, 2019

bors commented Jul 6, 2019

Centril Jun 20, 2019 •

edited

Loading

Centril Jun 24, 2019 •

edited

Loading

Centril Jun 21, 2019 •

edited

Loading

Centril Jun 25, 2019 •

edited

Loading

eddyb Jul 1, 2019 •

edited

Loading