Introduce `hir::ExprKind::Let` - Take 2 by c410-f3r · Pull Request #80357 · rust-lang/rust (original) (raw)

c410-f3r changed the title~~New hir let~~ [WIP] Introduce hir::ExprKind::Let - Take 2

Dec 24, 2020

c410-f3r changed the title~~[WIP] Introduce hir::ExprKind::Let - Take 2~~ Introduce hir::ExprKind::Let - Take 2

Feb 28, 2021

c410-f3r marked this pull request as ready for review

February 28, 2021 22:12

This was referenced

Aug 16, 2021

camsteffen added a commit to camsteffen/rust that referenced this pull request

Aug 19, 2021

…=Manishearth

Fix clippy::collapsible_match with let expressions

This fixes rust-lang/rust-clippy#7575 which is a regression from rust-lang#80357. I am fixing the bug here instead of in the clippy repo (if that's okay) because a) the regression has not been synced yet and b) I would like to land the fix on nightly asap.

The fix is basically to re-generalize match and if let for the lint implementation (they were split because if let no longer desugars to match in the HIR).

Also fixes rust-lang/rust-clippy#7586 cc @rust-lang/clippy @xFrednet do you want to review this?

bors added a commit to rust-lang-ci/rust that referenced this pull request

Aug 22, 2021

…anishearth

Fix clippy::collapsible_match with let expressions

The fix is basically to re-generalize match and if let for the lint implementation (they were split because if let no longer desugars to match in the HIR).

Also fixes rust-lang/rust-clippy#7586 and fixes rust-lang/rust-clippy#7591 cc @rust-lang/clippy @xFrednet do you want to review this?

This was referenced

Aug 24, 2021

flip1995 pushed a commit to flip1995/rust that referenced this pull request

Sep 3, 2021

…anishearth

Fix clippy::collapsible_match with let expressions

The fix is basically to re-generalize match and if let for the lint implementation (they were split because if let no longer desugars to match in the HIR).

Also fixes rust-lang/rust-clippy#7586 and fixes rust-lang/rust-clippy#7591 cc @rust-lang/clippy @xFrednet do you want to review this?

bors added a commit to rust-lang-ci/rust that referenced this pull request

Oct 3, 2021

…earth

Add expansion to while desugar spans

In the same vein as rust-lang#88163, this reverts a change in Clippy behavior as a result of rust-lang#80357 (and reverts some #[allow]s): This changes clippy::blocks_in_if_conditions to not fire on while loops. Though we might actually want Clippy to lint those cases, we should introduce the change purposefully, with tests, and possibly under a different lint name.

The actual change here is to add a desugaring expansion to the spans when lowering a while loop.

r? @Manishearth

flip1995 pushed a commit to flip1995/rust that referenced this pull request

Oct 7, 2021

…earth

Add expansion to while desugar spans

The actual change here is to add a desugaring expansion to the spans when lowering a while loop.

r? @Manishearth

smoelius added a commit to trailofbits/dylint that referenced this pull request

Dec 29, 2021

smoelius added a commit to trailofbits/dylint that referenced this pull request

Dec 30, 2021

smoelius added a commit to trailofbits/dylint that referenced this pull request

Jan 6, 2022

JohnTitor added a commit to JohnTitor/rust that referenced this pull request

Jul 17, 2022

…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:

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.

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
On 2018-07-12, eRFC: if- and while-let-chains, take 2
On 2018-08-24, Tracking issue for eRFC 2497, "if- and while-let-chains, take 2
On 2019-03-19, Run branch cleanup after copy prop
On 2019-03-26, Generalize diagnostic for x = y where bool is the expected type
On 2019-04-24, Introduce hir::ExprKind::Use and employ in for loop desugaring
On 2019-03-19, [let_chains, 1/6] Remove hir::ExprKind::If
On 2019-05-15, [let_chains, 2/6] Introduce Let(..) in AST, remove IfLet + WhileLet and parse let chains
On 2019-06-20, [let_chains, 3/6] And then there was only Loop
On 2020-11-22, Reintroduce hir::ExprKind::If
On 2020-12-24, Introduce hir::ExprKind::Let - Take 2
On 2021-02-19, Lower condition of if expression before it's "then" block
On 2021-09-01, Fix drop handling for if let expressions
On 2021-09-04, Formally implement let chains
On 2022-01-19, Add tests to ensure that let_chains works with if_let_guard
On 2022-01-18, Introduce enhanced_binary_op feature
On 2022-01-22, Fix let_chains and if_let_guard feature flags
On 2022-02-25, Initiate the inner usage of let_chains
On 2022-01-28, [WIP] Introduce ast::StmtKind::LetElse to allow the usage of let_else with let_chains
On 2022-02-26, 1 - Make more use of let_chains
On 2022-02-26, 2 - Make more use of let_chains
On 2022-02-27, 3 - Make more use of let_chains
On 2022-02-28, 4 - Make more use of let_chains
On 2022-02-28, 5 - Make more use of let_chains
On 2022-02-28, 6 - Make more use of let_chains
On 2022-03-01, 7 - Make more use of let_chains
On 2022-03-01, 8 - Make more use of let_chains
On 2022-03-01, 9 - Make more use of let_chains
On 2022-03-08, Warn users about || in let chain expressions

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.

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.

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

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

workingjubilee pushed a commit to tcdi/postgrestd that referenced this pull request

Sep 15, 2022

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:

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.

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
On 2018-07-12, eRFC: if- and while-let-chains, take 2
On 2018-08-24, Tracking issue for eRFC 2497, "if- and while-let-chains, take 2
On 2019-03-19, Run branch cleanup after copy prop
On 2019-03-26, Generalize diagnostic for x = y where bool is the expected type
On 2019-04-24, Introduce hir::ExprKind::Use and employ in for loop desugaring
On 2019-03-19, [let_chains, 1/6] Remove hir::ExprKind::If
On 2019-05-15, [let_chains, 2/6] Introduce Let(..) in AST, remove IfLet + WhileLet and parse let chains
On 2019-06-20, [let_chains, 3/6] And then there was only Loop
On 2020-11-22, Reintroduce hir::ExprKind::If
On 2020-12-24, Introduce hir::ExprKind::Let - Take 2
On 2021-02-19, Lower condition of if expression before it's "then" block
On 2021-09-01, Fix drop handling for if let expressions
On 2021-09-04, Formally implement let chains
On 2022-01-19, Add tests to ensure that let_chains works with if_let_guard
On 2022-01-18, Introduce enhanced_binary_op feature
On 2022-01-22, Fix let_chains and if_let_guard feature flags
On 2022-02-25, Initiate the inner usage of let_chains
On 2022-01-28, [WIP] Introduce ast::StmtKind::LetElse to allow the usage of let_else with let_chains
On 2022-02-26, 1 - Make more use of let_chains
On 2022-02-26, 2 - Make more use of let_chains
On 2022-02-27, 3 - Make more use of let_chains
On 2022-02-28, 4 - Make more use of let_chains
On 2022-02-28, 5 - Make more use of let_chains
On 2022-02-28, 6 - Make more use of let_chains
On 2022-03-01, 7 - Make more use of let_chains
On 2022-03-01, 8 - Make more use of let_chains
On 2022-03-01, 9 - Make more use of let_chains
On 2022-03-08, Warn users about || in let chain expressions

Divergent non-terminal matchers

More specifically, rust-lang/rust#86730.

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);
}

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

The introductory snippet would then be written as the following.

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

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

Introduce hir::ExprKind::Let - Take 2 by c410-f3r · Pull Request #80357 · rust-lang/rust (original) (raw)

Stabilization proposal

What is stabilized

Motivation

What isn't stabilized

History

Divergent non-terminal matchers

Alternative syntax

Tests

Possible future work

Stabilization proposal

What is stabilized

Motivation

What isn't stabilized

History

Divergent non-terminal matchers

Alternative syntax

Tests

Possible future work

Introduce `hir::ExprKind::Let` - Take 2 by c410-f3r · Pull Request #80357 · rust-lang/rust (original) (raw)