Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Initiate the inner usage of let_chains #94376

Merged
merged 1 commit into from
Feb 26, 2022
Merged

Conversation

c410-f3r
Copy link
Contributor

@c410-f3r c410-f3r commented Feb 25, 2022

The intention here is create a strong and robust foundation for a possible future stabilization so please, do not let the lack of any external tool support prevent the merge of this PR. Besides, let_chains is useful by itself.

cc #53667

@rustbot rustbot added the T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. label Feb 25, 2022
@rust-highfive
Copy link
Collaborator

r? @petrochenkov

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

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Feb 25, 2022
Comment on lines +28 to 42
#![allow(rustc::potential_query_instability)]
#![doc(html_root_url = "https://doc.rust-lang.org/nightly/nightly-rustc/")]
#![feature(array_windows)]
#![feature(bool_to_option)]
#![feature(box_patterns)]
#![feature(control_flow_enum)]
#![feature(crate_visibility_modifier)]
#![feature(if_let_guard)]
#![feature(iter_intersperse)]
#![feature(iter_order_by)]
#![feature(let_chains)]
#![feature(let_else)]
#![feature(never_type)]
#![feature(nll)]
#![feature(control_flow_enum)]
#![recursion_limit = "256"]
Copy link
Contributor Author

@c410-f3r c410-f3r Feb 25, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Re-ordered in alphabetical order

Comment on lines +1498 to +1506
if let Some((method, args)) = Self::inherent_atomic_method_call(cx, expr, &[sym::load, sym::store])
&& let Some((ordering_arg, invalid_ordering)) = match method {
sym::load => Some((&args[1], sym::Release)),
sym::store => Some((&args[2], sym::Acquire)),
_ => None,
};

if let ExprKind::Path(QPath::Resolved(_, path)) = ordering_arg.kind;
if let Res::Def(DefKind::Ctor(..), ctor_id) = path.res;
if Self::matches_ordering(cx, ctor_id, &[invalid_ordering, sym::AcqRel]);
then {
cx.struct_span_lint(INVALID_ATOMIC_ORDERING, ordering_arg.span, |diag| {
if method == sym::load {
diag.build("atomic loads cannot have `Release` or `AcqRel` ordering")
.help("consider using ordering modes `Acquire`, `SeqCst` or `Relaxed`")
.emit()
} else {
debug_assert_eq!(method, sym::store);
diag.build("atomic stores cannot have `Acquire` or `AcqRel` ordering")
.help("consider using ordering modes `Release`, `SeqCst` or `Relaxed`")
.emit();
}
});
}
&& let ExprKind::Path(QPath::Resolved(_, path)) = ordering_arg.kind
&& let Res::Def(DefKind::Ctor(..), ctor_id) = path.res
&& Self::matches_ordering(cx, ctor_id, &[invalid_ordering, sym::AcqRel])
Copy link
Contributor Author

@c410-f3r c410-f3r Feb 25, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Diff is scary but no logic was changed. In fact, everything was simply a matter of renaming if let ... ; if let ... ; to if let ... && let ...

@petrochenkov
Copy link
Contributor

@bors r+ rollup

@bors
Copy link
Contributor

bors commented Feb 26, 2022

📌 Commit f2e5e45 has been approved by petrochenkov

@bors 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 Feb 26, 2022
@bors
Copy link
Contributor

bors commented Feb 26, 2022

⌛ Testing commit f2e5e45 with merge 6f681a8...

@bors
Copy link
Contributor

bors commented Feb 26, 2022

☀️ Test successful - checks-actions
Approved by: petrochenkov
Pushing 6f681a8 to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Feb 26, 2022
@bors bors merged commit 6f681a8 into rust-lang:master Feb 26, 2022
@rustbot rustbot added this to the 1.61.0 milestone Feb 26, 2022
c410-f3r added a commit to c410-f3r/rust that referenced this pull request Feb 26, 2022
@bors bors mentioned this pull request Feb 26, 2022
@rust-timer
Copy link
Collaborator

Finished benchmarking commit (6f681a8): comparison url.

Summary: This benchmark run did not return any relevant results.

If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf.

@rustbot label: -perf-regression

matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Feb 26, 2022
bors added a commit to rust-lang-ci/rust that referenced this pull request Feb 27, 2022
c410-f3r added a commit to c410-f3r/rust that referenced this pull request Feb 27, 2022
Dylan-DPC added a commit to Dylan-DPC/rust that referenced this pull request Feb 27, 2022
…an-DPC

1 - Make more use of `let_chains`

Continuation of rust-lang#94376.

cc rust-lang#53667
Dylan-DPC added a commit to Dylan-DPC/rust that referenced this pull request Feb 27, 2022
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Feb 27, 2022
…an-DPC

1 - Make more use of `let_chains`

Continuation of rust-lang#94376.

cc rust-lang#53667
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Feb 27, 2022
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Feb 27, 2022
…an-DPC

1 - Make more use of `let_chains`

Continuation of rust-lang#94376.

cc rust-lang#53667
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Feb 27, 2022
c410-f3r added a commit to c410-f3r/rust that referenced this pull request Feb 28, 2022
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Feb 28, 2022
c410-f3r added a commit to c410-f3r/rust that referenced this pull request Mar 1, 2022
Dylan-DPC added a commit to Dylan-DPC/rust that referenced this pull request Mar 1, 2022
…ebank

5 - Make more use of `let_chains`

Continuation of rust-lang#94376.

cc rust-lang#53667
c410-f3r added a commit to c410-f3r/rust that referenced this pull request Mar 1, 2022
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Mar 1, 2022
Dylan-DPC added a commit to Dylan-DPC/rust that referenced this pull request Mar 1, 2022
…an-DPC

7 - Make more use of `let_chains`

Continuation of rust-lang#94376.

cc rust-lang#53667
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Mar 1, 2022
…an-DPC

7 - Make more use of `let_chains`

Continuation of rust-lang#94376.

cc rust-lang#53667
c410-f3r added a commit to c410-f3r/rust that referenced this pull request Mar 1, 2022
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Mar 2, 2022
…an-DPC

7 - Make more use of `let_chains`

Continuation of rust-lang#94376.

cc rust-lang#53667
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Mar 2, 2022
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Mar 3, 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:

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

```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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
merged-by-bors This PR was explicitly merged by bors. S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants