Reintroduce hir::ExprKind::If #79328

c410-f3r · 2020-11-23T00:44:44Z

Basically copied and paste #59288/rust-lang/rust-clippy#4080 with some modifications.

The vast majority of tests were fixed and now there are only a few remaining. Since I am still unable to figure out the missing pieces, any help with the following list is welcome.

Unnecessary typeck exception: Cheated on this one to make CI green.
Incorrect span: Span should reference then and else separately.
New note regarding assert!: Modified but not "wrong". Maybe can be a good thing?
Inverted report location: Modified but not "wrong". Locations were inverted.
src/test/ui/point-to-type-err-cause-on-impl-trait-return.rs has weird errors: Not sure why this is happening.
Missing diagnostic: ???

rust-highfive · 2020-11-23T00:44:47Z

r? @davidtwco

(rust_highfive has picked a reviewer for you, use r? to override)

jyn514 · 2020-11-23T01:27:51Z

Why is this useful?

c410-f3r · 2020-11-23T10:14:11Z

@jyn514 This is a important step towards #53667

jyn514 · 2020-11-23T13:48:32Z

That issue says:

for the record, the discussed step list is

remove if from HIR and make lowering emit a match

What changed since then?

c410-f3r · 2020-11-23T15:50:56Z

I don't know exactly what changed since that time. Maybe someone better than me in this field could make a better explanation?

matthewjasper · 2020-11-23T16:30:13Z

Lowering if let chains to nested matches would produce inconsistent drop orders with if ... && .... Also having actual let expressions, at least in HIR, is more flexible in the long run.

compiler/rustc_ast_lowering/src/expr.rs

bors · 2020-11-29T05:20:03Z

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

Note that reviewers usually do not review pull requests until merge conflicts are resolved! Once you resolve the conflicts, you should change the labels applied by bors to indicate that your PR is ready for review. Post this as a comment to change the labels:

@rustbot modify labels: +S-waiting-on-review -S-waiting-on-author

voidc · 2020-11-29T09:58:18Z

@jyn514 This is a important step towards #53667

How is this a step towards let-chains? In my understanding the next step was to introduce let expressions on the HIR (#68577).

c410-f3r · 2020-11-30T02:13:03Z

@voidc You should see the above comment about dropping order

src/test/ui/reachable/expr_if.stderr

c410-f3r · 2021-01-10T13:51:53Z

Tried to ./x.py test --bless src/test/run-make-fulldeps/coverage-spanview/ --stage 2 with build.profiler = true but ended up with 115 deleted files 👍

2021-01-10T05:12:49.9837264Z Check compiletest suite=run-make-fulldeps mode=run-make (**x86_64-pc-windows-msvc** -> **x86_64-pc-windows-msvc**)

Also, these tests are windows related :/

matthewjasper · 2021-01-12T20:34:59Z

I've pushed the blessed test output

c410-f3r · 2021-01-12T21:24:26Z

@matthewjasper Thanks! It is very kind of you

I may have to face this scenario again in the future and if it does, should I spin-up a Windows environment to bless the tests?

matthewjasper · 2021-01-14T08:48:03Z

I guess creating a Windows environment is the easiest way to bless these tests if you need to do it yourself.
@bors r+

bors · 2021-01-14T08:48:04Z

📌 Commit b0ac0fb has been approved by matthewjasper

bors · 2021-01-14T14:42:04Z

⌛ Testing commit b0ac0fb with merge d03fe84...

bors · 2021-01-14T17:26:57Z

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

Reintroduce hir::ExprKind::If Basically copied and paste rust-lang#59288/rust-lang/rust-clippy#4080 with some modifications. The vast majority of tests were fixed and now there are only a few remaining. Since I am still unable to figure out the missing pieces, any help with the following list is welcome. - [ ] **Unnecessary `typeck` exception**: [Cheated on this one to make CI green.](https://github.com/rust-lang/rust/pull/79328/files#diff-3faee9ba23fc54a12b7c43364ba81f8c5660045c7e1d7989a02a0cee1c5b2051) - [x] **Incorrect span**: [Span should reference `then` and `else` separately.](https://github.com/rust-lang/rust/pull/79328/files#diff-cf2c46e82222ee4b1037a68fff8a1af3c4f1de7a6b3fd798aacbf3c0475abe3d) - [x] **New note regarding `assert!`**: [Modified but not "wrong". Maybe can be a good thing?](https://github.com/rust-lang/rust/pull/79328/files#diff-9e0d7c89ed0224e2b62060c957177c27db43c30dfe3c2974cb6b5091cda9cfb5) - [x] **Inverted report location**: [Modified but not "wrong". Locations were inverted.](https://github.com/rust-lang/rust/pull/79328/files#diff-f637ce7c1f68d523a165aa9651765df05e36c4d7d279194b1a6b28b48a323691) - [x] **`src/test/ui/point-to-type-err-cause-on-impl-trait-return.rs` has weird errors**: [Not sure why this is happening.](https://github.com/rust-lang/rust/pull/79328/files#diff-c823c09660f5b112f95e97e8ff71f1797b6c7f37dbb3d16f8e98bbaea8072e95) - [x] **Missing diagnostic**: [???](https://github.com/rust-lang/rust/pull/79328/files#diff-6b8ab09360d725ba4513933827f9796b42ff9522b0690f80b76de067143af2fc)

Introduce `hir::ExprKind::Let` - Take 2 Builds on rust-lang#68577 and depends on rust-lang#79328. cc rust-lang#53667

…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 davidtwco Nov 23, 2020

rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Nov 23, 2020

c410-f3r force-pushed the hir-if branch from 134cbbf to 73364c9 Compare November 23, 2020 11:29

c410-f3r force-pushed the hir-if branch from 73364c9 to e2714d7 Compare November 23, 2020 15:52

matthewjasper assigned matthewjasper and unassigned davidtwco Nov 23, 2020

c410-f3r force-pushed the hir-if branch from e2714d7 to 12e945f Compare November 25, 2020 01:04

c410-f3r commented Nov 25, 2020

View reviewed changes

compiler/rustc_ast_lowering/src/expr.rs Outdated Show resolved Hide resolved

c410-f3r commented Nov 25, 2020

View reviewed changes

compiler/rustc_ast_lowering/src/expr.rs Outdated Show resolved Hide resolved

c410-f3r force-pushed the hir-if branch 2 times, most recently from 3e561ce to ea0168d Compare November 26, 2020 20:02

jyn514 added A-frontend Area: Compiler frontend (errors, parsing and HIR) A-HIR Area: The high-level intermediate representation (HIR) T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Nov 26, 2020

c410-f3r force-pushed the hir-if branch from ea0168d to 494a451 Compare November 30, 2020 02:12

c410-f3r commented Nov 30, 2020

View reviewed changes

src/test/ui/reachable/expr_if.stderr Outdated Show resolved Hide resolved

c410-f3r force-pushed the hir-if branch 5 times, most recently from cc8b0ed to 5b996f4 Compare December 2, 2020 00:13

bors added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jan 10, 2021

Bless profiler run make tests

b0ac0fb

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 Jan 14, 2021

bors added the merged-by-bors This PR was explicitly merged by bors. label Jan 14, 2021

bors merged commit d03fe84 into rust-lang:master Jan 14, 2021

rustbot added this to the 1.51.0 milestone Jan 14, 2021

c410-f3r mentioned this pull request Mar 8, 2021

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

Open

14 tasks

bors added a commit to rust-lang-ci/rust that referenced this pull request Aug 16, 2021

Auto merge of rust-lang#80357 - c410-f3r:new-hir-let, r=matthewjasper

2a6fb9a

Introduce `hir::ExprKind::Let` - Take 2 Builds on rust-lang#68577 and depends on rust-lang#79328. cc rust-lang#53667

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

Reintroduce hir::ExprKind::If #79328

Reintroduce hir::ExprKind::If #79328

c410-f3r commented Nov 23, 2020 •

edited

Loading

rust-highfive commented Nov 23, 2020

jyn514 commented Nov 23, 2020

c410-f3r commented Nov 23, 2020

jyn514 commented Nov 23, 2020

c410-f3r commented Nov 23, 2020 •

edited

Loading

matthewjasper commented Nov 23, 2020

bors commented Nov 29, 2020

voidc commented Nov 29, 2020

c410-f3r commented Nov 30, 2020

c410-f3r commented Jan 10, 2021 •

edited

Loading

matthewjasper commented Jan 12, 2021

c410-f3r commented Jan 12, 2021

matthewjasper commented Jan 14, 2021

bors commented Jan 14, 2021

bors commented Jan 14, 2021

bors commented Jan 14, 2021

Reintroduce hir::ExprKind::If #79328

Reintroduce hir::ExprKind::If #79328

Conversation

c410-f3r commented Nov 23, 2020 • edited Loading

rust-highfive commented Nov 23, 2020

jyn514 commented Nov 23, 2020

c410-f3r commented Nov 23, 2020

jyn514 commented Nov 23, 2020

c410-f3r commented Nov 23, 2020 • edited Loading

matthewjasper commented Nov 23, 2020

bors commented Nov 29, 2020

voidc commented Nov 29, 2020

c410-f3r commented Nov 30, 2020

c410-f3r commented Jan 10, 2021 • edited Loading

matthewjasper commented Jan 12, 2021

c410-f3r commented Jan 12, 2021

matthewjasper commented Jan 14, 2021

bors commented Jan 14, 2021

bors commented Jan 14, 2021

bors commented Jan 14, 2021

c410-f3r commented Nov 23, 2020 •

edited

Loading

c410-f3r commented Nov 23, 2020 •

edited

Loading

c410-f3r commented Jan 10, 2021 •

edited

Loading