Introduce hir::ExprKind::Use and employ in for loop desugaring. #60225
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
rust-highfive
added
the
S-waiting-on-review
|
@bors try |
bors
added a commit
that referenced
this pull request
Apr 24, 2019
Introduce hir::ExprKind::Use and employ in for loop desugaring.
In the `for $pat in $expr $block` desugaring we end with a `{ let _result = $match_expr; _result }` construct which makes `for` loops into a terminating scope and affects drop order. The construct was introduced in year 2015 by @pnkfelix in #21984.
This PR replaces the construct with `hir::ExprKind::Use(P<hir::Expr>)` which is equivalent semantically but should hopefully be less costly in terms of compile time performance (to be determined).
This is extracted out of 91b0abd from #59288 for easier review and so that the perf implications wrt. `for`-loops can be measured.
r? @oli-obk
Centril
commented
Apr 24, 2019
oli-obk
reviewed
Apr 24, 2019
|
☀️ Try build successful - checks-travis |
|
@rust-timer build 51f54bd |
|
Success: Queued 51f54bd with parent 0928511, comparison URL. |
|
Finished benchmarking try commit 51f54bd |
Centril
force-pushed
the
hir-exprkind-use-in-for-loops
branch
from
b755b93
to
487cc54
Compare
|
@oli-obk Adjusted the pretty printing... :) |
Centril
force-pushed
the
hir-exprkind-use-in-for-loops
branch
from
487cc54
to
f59f7d4
Compare
Here, ExprKind::Use(P<Expr>) tweaks the drop order to act the
same way as '{ let _tmp = expr; _tmp }' does.
Centril
force-pushed
the
hir-exprkind-use-in-for-loops
branch
from
f59f7d4
to
4bd36ab
Compare
|
@bors r=oli-obk |
|
📌 Commit 4bd36ab has been approved by |
bors
added
S-waiting-on-bors
|
⌛ Testing commit 4bd36ab with merge e54563c2e454c188cc51b84f81eaf69db54a9ca8... |
|
💔 Test failed - checks-travis |
|
The job Click to expand the log.I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
bors
added
S-waiting-on-review
|
@bors retry timeout |
bors
added
S-waiting-on-bors
Centril
added a commit
to Centril/rust
that referenced
this pull request
Apr 25, 2019
…ps, r=oli-obk
Introduce hir::ExprKind::Use and employ in for loop desugaring.
In the `for $pat in $expr $block` desugaring we end with a `{ let _result = $match_expr; _result }` construct which makes `for` loops into a terminating scope and affects drop order. The construct was introduced in year 2015 by @pnkfelix in rust-lang#21984.
This PR replaces the construct with `hir::ExprKind::Use(P<hir::Expr>)` which is equivalent semantically but should hopefully be less costly in terms of compile time performance (to be determined).
This is extracted out of rust-lang@91b0abd from rust-lang#59288 for easier review and so that the perf implications wrt. `for`-loops can be measured.
r? @oli-obk
Centril
added a commit
to Centril/rust
that referenced
this pull request
Apr 25, 2019
…ps, r=oli-obk
Introduce hir::ExprKind::Use and employ in for loop desugaring.
In the `for $pat in $expr $block` desugaring we end with a `{ let _result = $match_expr; _result }` construct which makes `for` loops into a terminating scope and affects drop order. The construct was introduced in year 2015 by @pnkfelix in rust-lang#21984.
This PR replaces the construct with `hir::ExprKind::Use(P<hir::Expr>)` which is equivalent semantically but should hopefully be less costly in terms of compile time performance (to be determined).
This is extracted out of rust-lang@91b0abd from rust-lang#59288 for easier review and so that the perf implications wrt. `for`-loops can be measured.
r? @oli-obk
Centril
added a commit
to Centril/rust
that referenced
this pull request
Apr 26, 2019
…ps, r=oli-obk
Introduce hir::ExprKind::Use and employ in for loop desugaring.
In the `for $pat in $expr $block` desugaring we end with a `{ let _result = $match_expr; _result }` construct which makes `for` loops into a terminating scope and affects drop order. The construct was introduced in year 2015 by @pnkfelix in rust-lang#21984.
This PR replaces the construct with `hir::ExprKind::Use(P<hir::Expr>)` which is equivalent semantically but should hopefully be less costly in terms of compile time performance (to be determined).
This is extracted out of rust-lang@91b0abd from rust-lang#59288 for easier review and so that the perf implications wrt. `for`-loops can be measured.
r? @oli-obk
bors
added a commit
that referenced
this pull request
Apr 26, 2019
Rollup of 12 pull requests Successful merges: - #59734 (Prevent failure in case no space left on device in rustdoc) - #59940 (Set cfg(test) when rustdoc is running with --test option) - #60134 (Fix index-page generation) - #60165 (Add Pin::{into_inner,into_inner_unchecked}) - #60183 (Chalkify: Add builtin Copy/Clone) - #60225 (Introduce hir::ExprKind::Use and employ in for loop desugaring.) - #60247 (Implement Debug for Place using Place::iterate) - #60259 (Derive Default instead of new in applicable lint) - #60267 (Add feature-gate for f16c target feature) - #60284 (Do not allow const generics to depend on type parameters) - #60285 (Do not ICE when checking types against foreign fn) - #60289 (Make `-Z allow-features` work for stdlib features) Failed merges: r? @ghost
Manishearth
reviewed
Apr 27, 2019
| @@ -1486,6 +1488,10 @@ pub enum ExprKind { | |||
| Cast(P<Expr>, P<Ty>), | |||
| /// A type reference (e.g., `Foo`). | |||
| Type(P<Expr>, P<Ty>), | |||
| /// Semantically equivalent to `{ let _t = expr; _t }`. | |||
| /// Maps directly to `hair::ExprKind::Use`. | |||
| /// Only exists to tweak the drop order in HIR. | |||
There was a problem hiding this comment.
Can we have more docs on where this is introduced and why it exists? As it stands it's pretty confusing
There was a problem hiding this comment.
It is used in the for loop desugaring as seen in this PR and also in #59288 (see lowering.rs).
There was a problem hiding this comment.
I'm not asking you to explain it to me, I figured it out, I'm saying that this should be in the docs.
There was a problem hiding this comment.
Sure why not. Some parts haven't been merged yet so it would be slightly weird to talk about future events in the docs. Can you file an issue for now`?
There was a problem hiding this comment.
I don't find the name... useful (sorry). I'd call this SomethingScope, which for the lack of a better option would be TerminatingScope.
I believe that ExprKind::Use elsewhere has nothing to do with scopes (just like mir::Rvalue::Use doesn't), so using Use is misleading.
There was a problem hiding this comment.
@eddyb Fwiw, I contemplated ExprKind::Terminating. I agree completely that ::Use sucks but I didn't have anything super better at the time.
Manishearth
added a commit
to rust-lang/rust-clippy
that referenced
this pull request
Apr 27, 2019
Introduced in rust-lang/rust#60225
Manishearth
added a commit
to rust-lang/rust-clippy
that referenced
this pull request
Apr 27, 2019
Introduced in rust-lang/rust#60225
bors
added a commit
to rust-lang/rust-clippy
that referenced
this pull request
Apr 28, 2019
Fix breakage due to rust-lang/rust#60225 Wrote this up before I saw that Manish already started on a fix in #4038. It no doubt contains errors. Feel free to close.
Centril
added a commit
to Centril/rust
that referenced
this pull request
Apr 30, 2019
…-drop-temps, r=oli-obk Rename hir::ExprKind::Use to ::DropTemps and improve docs. Addresses rust-lang#60225 (comment). r? @oli-obk cc @eddyb @Manishearth
Centril
added a commit
to Centril/rust
that referenced
this pull request
May 1, 2019
…-drop-temps, r=oli-obk Rename hir::ExprKind::Use to ::DropTemps and improve docs. Addresses rust-lang#60225 (comment). r? @oli-obk cc @eddyb @Manishearth
Centril
added a commit
to Centril/rust
that referenced
this pull request
May 1, 2019
…-drop-temps, r=oli-obk Rename hir::ExprKind::Use to ::DropTemps and improve docs. Addresses rust-lang#60225 (comment). r? @oli-obk cc @eddyb @Manishearth
Centril
added a commit
to Centril/rust
that referenced
this pull request
May 1, 2019
…-drop-temps, r=oli-obk Rename hir::ExprKind::Use to ::DropTemps and improve docs. Addresses rust-lang#60225 (comment). r? @oli-obk cc @eddyb @Manishearth
14 tasks
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
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
In the
for $pat in $expr $blockdesugaring we end with a{ let _result = $match_expr; _result }construct which makesforloops into a terminating scope and affects drop order. The construct was introduced in year 2015 by @pnkfelix in #21984.This PR replaces the construct with
hir::ExprKind::Use(P<hir::Expr>)which is equivalent semantically but should hopefully be less costly in terms of compile time performance (to be determined).This is extracted out of 91b0abd from #59288 for easier review and so that the perf implications wrt.
for-loops can be measured.r? @oli-obk