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

Centril · 2018-08-24T12:25:32Z

Centril · 2019-03-11T15:09:03Z

I'm working on implementing this in a 3+ PR step fashion based on discussions with @oli-obk.

oli-obk · 2019-03-11T15:19:04Z

for the record, the discussed step list is

remove if from HIR and make lowering emit a match
remove if let from AST and instead have a let expression
"do the rest of the work" (might get split up further).

alexreg · 2019-03-11T15:26:21Z

I can't imagine 3 would be a particularly large step (enough to merit splitting), but 3 steps sounds fair enough.

@oli-obk

[WIP] [let_chains, 1/6] Remove hir::ExprKind::If Per #53667 (comment). r? @oli-obk

@oli-obk

[let_chains, 1/6] Remove hir::ExprKind::If Per #53667 (comment). r? @oli-obk

@Manishearth

[let_chains, 2/6] Introduce `Let(..)` in AST, remove IfLet + WhileLet and parse let chains Here we remove `ast::ExprKind::{IfLet, WhileLet}` and introduce `ast::ExprKind::Let`. Moreover, we also: + connect the parsing logic for let chains + introduce the feature gate + do some AST validation + rewire HIR lowering a bit. However, this does not connect the new syntax to semantics in HIR. That will be the subject of a subsequent PR. Per #53667 (comment). Next step after #59288. cc @Manishearth re. Clippy. r? @oli-obk

@Manishearth

[let_chains, 2/6] Introduce `Let(..)` in AST, remove IfLet + WhileLet and parse let chains Here we remove `ast::ExprKind::{IfLet, WhileLet}` and introduce `ast::ExprKind::Let`. Moreover, we also: + connect the parsing logic for let chains + introduce the feature gate + do some AST validation + rewire HIR lowering a bit. However, this does not connect the new syntax to semantics in HIR. That will be the subject of a subsequent PR. Per #53667 (comment). Next step after #59288. cc @Manishearth re. Clippy. r? @oli-obk

@Manishearth

[let_chains, 2/6] Introduce `Let(..)` in AST, remove IfLet + WhileLet and parse let chains Here we remove `ast::ExprKind::{IfLet, WhileLet}` and introduce `ast::ExprKind::Let`. Moreover, we also: + connect the parsing logic for let chains + introduce the feature gate + do some AST validation + rewire HIR lowering a bit. However, this does not connect the new syntax to semantics in HIR. That will be the subject of a subsequent PR. Per #53667 (comment). Next step after #59288. cc @Manishearth re. Clippy. r? @oli-obk

estk · 2019-05-20T16:00:32Z

@Centril I'm really jazzed about this feature, lmk if there is any work I can help with.

…compiler-errors Additional tests to ensure let is rejected during parsing In the original stabilization PR, @ `compiler-errors` has [pointed out](rust-lang#94927 (comment)) that rust-lang#97295 wasn't enough to address the concerns about having `let` in expressions being rejected at parsing time, instead of later. Thankfully, since then the situation has been greatly improved by rust-lang#115677. This PR adds some additional tests to `disallowed-positions.rs`, and adds two additional revisions to the "normal" case which is now given the `feature` name: * `no_feature`: Added to incorporate `disallowed-positions-without-feature-gate.rs` into the file, reducing duplication. * `nothing`: like feature, but all functions are cfg'd out. Ensures that the errors are really emitted during parsing. cc tracking issue rust-lang#53667

est31 · 2024-11-10T05:51:37Z

Stabilization report/PR: #132833

Rollup merge of rust-lang#132828 - est31:let_chains_parsing_tests, r=compiler-errors Additional tests to ensure let is rejected during parsing In the original stabilization PR, @ `compiler-errors` has [pointed out](rust-lang#94927 (comment)) that rust-lang#97295 wasn't enough to address the concerns about having `let` in expressions being rejected at parsing time, instead of later. Thankfully, since then the situation has been greatly improved by rust-lang#115677. This PR adds some additional tests to `disallowed-positions.rs`, and adds two additional revisions to the "normal" case which is now given the `feature` name: * `no_feature`: Added to incorporate `disallowed-positions-without-feature-gate.rs` into the file, reducing duplication. * `nothing`: like feature, but all functions are cfg'd out. Ensures that the errors are really emitted during parsing. cc tracking issue rust-lang#53667

…compiler-errors Additional tests to ensure let is rejected during parsing In the original stabilization PR, @ `compiler-errors` has [pointed out](rust-lang#94927 (comment)) that rust-lang#97295 wasn't enough to address the concerns about having `let` in expressions being rejected at parsing time, instead of later. Thankfully, since then the situation has been greatly improved by rust-lang#115677. This PR adds some additional tests to `disallowed-positions.rs`, and adds two additional revisions to the "normal" case which is now given the `feature` name: * `no_feature`: Added to incorporate `disallowed-positions-without-feature-gate.rs` into the file, reducing duplication. * `nothing`: like feature, but all functions are cfg'd out. Ensures that the errors are really emitted during parsing. cc tracking issue rust-lang#53667

See rust-lang/rust#53667 for more

* refactor: rename 'total_outstanding' amounts * refactor: rename 'outstanding_from_due' & expand disbursed outstanding functions * feat: introduce interest payment outstanding projection * chore: make overdue_duration optional * chore: implement 'defaults_at' * fix: unstable let expression See rust-lang/rust#53667 for more * test: fix maturity offset with 1 interest accrual * test: add interest_outstanding projection unit tests * chore: add interest_due_duration in gql layer * chore: add interestDueDuration defaults to frontend * chore: ignore 'DAYS' variant for 'durationPeriod' select

Mainly a preparation for (hopefully) soon-to-be-stabilized if-let-chains[^1] [^1]: rust-lang/rust#53667 Reviewed-on: https://codeberg.org/mergiraf/mergiraf/pulls/273 Reviewed-by: Antonin Delpeuch <[email protected]> Co-authored-by: Ada Alakbarova <[email protected]> Co-committed-by: Ada Alakbarova <[email protected]>

…inal, r=joshtriplett style guide: add let-chain rules Reopens rust-lang#110568 refs rust-lang#53667 and I suppose rust-lang#132833 as well This reflects the style rules that the style team had already agreed upon back in 2023, with the addition of literals in the lhs being permissible for single line formatting, and the removal of unnecessary language/example snippets around non-`&&` operators that was a small hiccup in the original PR. It also reflects current formatting behavior implemented in rustfmt (though note that the adjustment to include literals has been implemented & merged, but is still pending a sync to nightly)

Rollup merge of rust-lang#139456 - calebcartwright:style-let-chains-final, r=joshtriplett style guide: add let-chain rules Reopens rust-lang#110568 refs rust-lang#53667 and I suppose rust-lang#132833 as well This reflects the style rules that the style team had already agreed upon back in 2023, with the addition of literals in the lhs being permissible for single line formatting, and the removal of unnecessary language/example snippets around non-`&&` operators that was a small hiccup in the original PR. It also reflects current formatting behavior implemented in rustfmt (though note that the adjustment to include literals has been implemented & merged, but is still pending a sync to nightly)

Stabilize let chains in the 2024 edition # Stabilization report This proposes the stabilization of `let_chains` ([tracking issue], [RFC 2497]) in the [2024 edition] of Rust. [tracking issue]: rust-lang/rust#53667 [RFC 2497]: rust-lang/rfcs#2497 [2024 edition]: https://doc.rust-lang.org/nightly/edition-guide/rust-2024/index.html ## What is being stabilized The ability to `&&`-chain `let` statements inside `if` and `while` is being stabilized, allowing intermixture with boolean expressions. The patterns inside the `let` sub-expressions can be irrefutable or refutable. ```Rust struct FnCall<'a> { fn_name: &'a str, args: Vec<i32>, } fn is_legal_ident(s: &str) -> bool { s.chars() .all(|c| ('a'..='z').contains(&c) || ('A'..='Z').contains(&c)) } impl<'a> FnCall<'a> { fn parse(s: &'a str) -> Option<Self> { if let Some((fn_name, after_name)) = s.split_once("(") && !fn_name.is_empty() && is_legal_ident(fn_name) && let Some((args_str, "")) = after_name.rsplit_once(")") { let args = args_str .split(',') .map(|arg| arg.parse()) .collect::<Result<Vec<_>, _>>(); args.ok().map(|args| FnCall { fn_name, args }) } else { None } } fn exec(&self) -> Option<i32> { let iter = self.args.iter().copied(); match self.fn_name { "sum" => Some(iter.sum()), "max" => iter.max(), "min" => iter.min(), _ => None, } } } fn main() { println!("{:?}", FnCall::parse("sum(1,2,3)").unwrap().exec()); println!("{:?}", FnCall::parse("max(4,5)").unwrap().exec()); } ``` The feature will only be stabilized for the 2024 edition and future editions. Users of past editions will get an error with a hint to update the edition. closes #53667 ## Why 2024 edition? Rust generally tries to ship new features to all editions. So even the oldest editions receive the newest features. However, sometimes a feature requires a breaking change so much that offering the feature without the breaking change makes no sense. This occurs rarely, but has happened in the 2018 edition already with `async` and `await` syntax. It required an edition boundary in order for `async`/`await` to become keywords, and the entire feature foots on those keywords. In the instance of let chains, the issue is the drop order of `if let` chains. If we want `if let` chains to be compatible with `if let`, drop order makes it hard for us to [generate correct MIR]. It would be strange to have different behaviour for `if let ... {}` and `if true && let ... {}`. So it's better to [stay consistent with `if let`]. In edition 2024, [drop order changes] have been introduced to make `if let` temporaries be lived more shortly. These changes also affected `if let` chains. These changes make sense even if you don't take the `if let` chains MIR generation problem into account. But if we want to use them as the solution to the MIR generation problem, we need to restrict let chains to edition 2024 and beyond: for let chains, it's not just a change towards more sensible behaviour, but one required for correct function. [generate correct MIR]: rust-lang/rust#104843 [stay consistent with `if let`]: rust-lang/rust#103293 (comment) [drop order changes]: rust-lang/rust#124085 ## Introduction considerations As edition 2024 is very new, this stabilization PR only makes it possible to use let chains on 2024 without that feature gate, it doesn't mark that feature gate as stable/removed. I would propose to continue offering the `let_chains` feature (behind a feature gate) for a limited time (maybe 3 months after stabilization?) on older editions to allow nightly users to adopt edition 2024 at their own pace. After that, the feature gate shall be marked as *stabilized*, not removed, and replaced by an error on editions 2021 and below. ## Implementation history * History from before March 14, 2022 can be found in the [original stabilization PR] that was reverted. * rust-lang/rust#94927 * rust-lang/rust#94951 * rust-lang/rust#94974 * rust-lang/rust#95008 * rust-lang/rust#97295 * rust-lang/rust#98633 * rust-lang/rust#99731 * rust-lang/rust#102394 * rust-lang/rust#100526 * rust-lang/rust#100538 * rust-lang/rust#102998 * rust-lang/rust#103405 * rust-lang/rust#103293 * rust-lang/rust#107251 * rust-lang/rust#110568 * rust-lang/rust#115677 * rust-lang/rust#117743 * rust-lang/rust#117770 * rust-lang/rust#118191 * rust-lang/rust#119554 * rust-lang/rust#129394 * rust-lang/rust#132828 * rust-lang/reference#1179 * rust-lang/reference#1251 * rust-lang/rustfmt#5910 [original stabilization PR]: rust-lang/rust#94927 ## Adoption history ### In the compiler * History before March 14, 2022 can be found in the [original stabilization PR]. * rust-lang/rust#115983 * rust-lang/rust#116549 * rust-lang/rust#116688 ### Outside of the compiler * rust-lang/rust-clippy#11750 * [rspack](https://github.com/web-infra-dev/rspack) * [risingwave](https://github.com/risingwavelabs/risingwave) * [dylint](https://github.com/trailofbits/dylint) * [convex-backend](https://github.com/get-convex/convex-backend) * [tikv](https://github.com/tikv/tikv) * [Daft](https://github.com/Eventual-Inc/Daft) * [greptimedb](https://github.com/GreptimeTeam/greptimedb) ## Tests <details> ### Intentional restrictions [`partially-macro-expanded.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/rfcs/rfc-2294-if-let-guard/partially-macro-expanded.rs), [`macro-expanded.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/rfcs/rfc-2294-if-let-guard/macro-expanded.rs): it is possible to use macros to expand to both the pattern and the expression inside a let chain, but not to the entire `let pat = expr` operand. [`parens.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/rfcs/rfc-2294-if-let-guard/parens.rs): `if (let pat = expr)` is not allowed in chains [`ensure-that-let-else-does-not-interact-with-let-chains.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/rfcs/rfc-2497-if-let-chains/ensure-that-let-else-does-not-interact-with-let-chains.rs): `let...else` doesn't support chaining. ### Overlap with match guards [`move-guard-if-let-chain.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/rfcs/rfc-2294-if-let-guard/move-guard-if-let-chain.rs): test for the `use moved value` error working well in match guards. could maybe be extended with let chains that have more than one `let` [`shadowing.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/rfcs/rfc-2294-if-let-guard/shadowing.rs): shadowing in if let guards works as expected [`ast-validate-guards.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/rfcs/rfc-2497-if-let-chains/ast-validate-guards.rs): let chains in match guards require the match guards feature gate ### Simple cases from the early days PR #88642 has added some tests with very simple usages of `let else`, mostly as regression tests to early bugs. [`then-else-blocks.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/rfcs/rfc-2497-if-let-chains/then-else-blocks.rs) [`ast-lowering-does-not-wrap-let-chains.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/rfcs/rfc-2497-if-let-chains/ast-lowering-does-not-wrap-let-chains.rs) [`issue-90722.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/rfcs/rfc-2497-if-let-chains/issue-90722.rs) [`issue-92145.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/rfcs/rfc-2497-if-let-chains/issue-92145.rs) ### Drop order/MIR scoping tests [`issue-100276.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/drop/issue-100276.rs): let expressions on RHS aren't terminating scopes [`drop_order.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/drop/drop_order.rs): exhaustive temporary drop order test for various Rust constructs, including let chains [`scope.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/rfcs/rfc-2294-if-let-guard/scope.rs): match guard scoping test [`drop-scope.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/rfcs/rfc-2294-if-let-guard/drop-scope.rs): another match guard scoping test, ensuring that temporaries in if-let guards live for the arm [`drop_order_if_let_rescope.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/drop/drop_order_if_let_rescope.rs): if let rescoping on edition 2024, including chains [`mir_let_chains_drop_order.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/mir/mir_let_chains_drop_order.rs): comprehensive drop order test for let chains, distinguishes editions 2021 and 2024. [`issue-99938.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/rfcs/rfc-2497-if-let-chains/issue-99938.rs), [`issue-99852.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/mir/issue-99852.rs) both bad MIR ICEs fixed by #102394 ### Linting [`irrefutable-lets.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/rfcs/rfc-2497-if-let-chains/irrefutable-lets.rs): trailing and leading irrefutable let patterns get linted for, others don't. The lint is turned off for `else if`. [`issue-121070-let-range.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/lint/issue-121070-let-range.rs): regression test for false positive of the unused parens lint, precedence requires the `()`s here ### Parser: intentional restrictions [`disallowed-positions.rs`](https://github.com/rust-lang/rust/blob/2128d8df0e858edcbe6a0861bac948b88b7fabc3/tests/ui/rfcs/rfc-2497-if-let-chains/disallowed-positions.rs): `let` in expression context is rejected everywhere except at the top level [`invalid-let-in-a-valid-let-context.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/rfcs/rfc-2497-if-let-chains/invalid-let-in-a-valid-let-context.rs): nested `let` is not allowed (let's are no legal expressions just because they are allowed in `if` and `while`). ### Parser: recovery [`issue-103381.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/parser/issues/issue-103381.rs): Graceful recovery of incorrect chaining of `if` and `if let` [`semi-in-let-chain.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/parser/semi-in-let-chain.rs): Ensure that stray `;`s in let chains give nice errors (`if_chain!` users might be accustomed to `;`s) [`deli-ident-issue-1.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/parser/deli-ident-issue-1.rs), [`brace-in-let-chain.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/parser/brace-in-let-chain.rs): Ensure that stray unclosed `{`s in let chains give nice errors and hints ### Misc [`conflicting_bindings.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/pattern/usefulness/conflicting_bindings.rs): the conflicting bindings check also works in let chains. Personally, I'd extend it to chains with multiple let's as well. [`let-chains-attr.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/expr/if/attrs/let-chains-attr.rs): attributes work on let chains ### Tangential tests with `#![feature(let_chains)]` [`if-let.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/coverage/branch/if-let.rs): MC/DC coverage tests for let chains [`logical_or_in_conditional.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/mir-opt/building/logical_or_in_conditional.rs): not really about let chains, more about dropping/scoping behaviour of `||` [`stringify.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/macros/stringify.rs): exhaustive test of the `stringify` macro [`expanded-interpolation.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/unpretty/expanded-interpolation.rs), [`expanded-exhaustive.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/unpretty/expanded-exhaustive.rs): Exhaustive test of `-Zunpretty` [`diverges-not.rs`](https://github.com/rust-lang/rust/blob/4adafcf40aa6064d2bbcb44bc1a50b3b1e86e5e0/tests/ui/rfcs/rfc-0000-never_patterns/diverges-not.rs): Never type, mostly tangential to let chains </details> ## Possible future work * There is proposals to allow `if let Pat(bindings) = expr {}` to be written as `if expr is Pat(bindings) {}` ([RFC 3573]). `if let` chains are a natural extension of the already existing `if let` syntax, and I'd argue orthogonal towards `is` syntax. * rust-lang/lang-team#297 * One could have similar chaining inside `let ... else` statements. There is no proposed RFC for this however, nor is it implemented on nightly. * Match guards have the `if` keyword as well, but on stable Rust, they don't support `let`. The functionality is available via an unstable feature ([`if_let_guard` tracking issue]). Stabilization of let chains affects this feature in so far as match guards containing let chains now only need the `if_let_guard` feature gate be present instead of also the `let_chains` feature (NOTE: this PR doesn't implement this simplification, it's left for future work). [RFC 3573]: rust-lang/rfcs#3573 [`if_let_guard` tracking issue]: rust-lang/rust#51114 ## Open questions / blockers - [ ] bad recovery if you don't put a `let` (I don't think this is a blocker): [#117977](rust-lang/rust#117977) - [x] An instance where a temporary lives shorter than with nested ifs, breaking compilation: [#103476](rust-lang/rust#103476). Personally I don't think this is a blocker either, as it's an edge case. Edit: turns out to not reproduce in edition 2025 any more, due to let rescoping. regression test added in #133093 - [x] One should probably extend the tests for `move-guard-if-let-chain.rs` and `conflicting_bindings.rs` to have chains with multiple let's: done in 133093 - [x] Parsing rejection tests: addressed by rust-lang/rust#132828 - [x] [Style](https://rust-lang.zulipchat.com/#narrow/channel/346005-t-style/topic/let.20chains.20stabilization.20and.20formatting): rust-lang/rust#139456 - [x] rust-lang/rust#86730 explicitly mentions `let_else`. I think we can live with `let pat = expr` not evaluating as `expr` for macro_rules macros, especially given that `let pat = expr` is not a legal expression anywhere except inside `if` and `while`. - [x] Documentation in the reference: rust-lang/reference#1740 - [x] Add chapter to the Rust 2024 [edition guide]: rust-lang/edition-guide#337 - [x] Resolve open questions on desired drop order. [original reference PR]: rust-lang/reference#1179 [edition guide]: https://github.com/rust-lang/edition-guide

Clippy, with the nightly toolchain, complains as follows: error: this `if` statement can be collapsed --> cli/bin/completions.rs:75:17 | 75 | / if let Some((arg_side, value_side)) = word.split_once("=") { 76 | | if let Some(arg) = node.find_arg(arg_side) { 77 | | // if left side of = is arg and it has choices, offer them 78 | | if !arg.choices.is_empty() { ... | 90 | | } | |_________________^ | = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#collapsible_if = note: `-D clippy::collapsible-if` implied by `-D warnings` = help: to override `-D warnings` add `#[allow(clippy::collapsible_if)]` help: collapse nested if block | 75 ~ if let Some((arg_side, value_side)) = word.split_once("=") 76 ~ && let Some(arg) = node.find_arg(arg_side) { 77 | // if left side of = is arg and it has choices, offer them ... 88 | } 89 ~ } | However, applying the suggested fix leads to compiler errors with the stable toolchain: error[E0658]: `let` expressions in this position are unstable --> cli/bin/completions.rs:75:20 | 75 | if let Some((arg_side, value_side)) = word.split_once("=") | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | = note: see issue #53667 <rust-lang/rust#53667> for more information error[E0658]: `let` expressions in this position are unstable --> cli/bin/completions.rs:76:24 | 76 | && let Some(arg) = node.find_arg(arg_side) | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | = note: see issue #53667 <rust-lang/rust#53667> for more information For more information about this error, try `rustc --explain E0658`. error: could not compile `dataplane-cli` (bin "cli" test) due to 2 previous errors This is apparently better supported in beta and nightly, but not in the stable version just yet. Just silence the warning for now. Same happens at a few other locations. We should remove the macros and "collapse" the "if"s once we have switched to Rust v1.88 as stable. Signed-off-by: Quentin Monnet <[email protected]>

Centril added B-RFC-approved Blocker: Approved by a merged RFC but not yet implemented. T-lang Relevant to the language team, which will review and decide on the PR/issue. C-tracking-issue Category: An issue tracking the progress of sth. like the implementation of an RFC labels Aug 24, 2018

This was referenced Aug 24, 2018

eRFC: if- and while-let-chains, take 2 rust-lang/rfcs#2497

Merged

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

Closed

marco-c mentioned this issue Oct 8, 2018

Use if-let chains when available to clean up some code mozilla/grcov#195

Closed

This was referenced Dec 24, 2018

Allow negation of if let rust-lang/rfcs#2616

Open

Tracking issue for RFC 2046, label-break-value #48594

Closed

dherman mentioned this issue Jan 3, 2019

Skip Scanning Index with Exact Version volta-cli/volta#228

Merged

Centril self-assigned this Mar 11, 2019

This was referenced Mar 17, 2019

Introduce the assert_matches! macro family #59260

Closed

[let_chains, 1/6] Remove hir::ExprKind::If #59288

Merged

Centril mentioned this issue Apr 15, 2019

Cognitive Complexity (step 2 (and maybe 3) out of 3+): implementation! rust-lang/rust-clippy#3963

Closed

5 tasks

bors added a commit that referenced this issue Apr 17, 2019

Auto merge of #59288 - Centril:hir-if-to-match, r=<try>

6a4b867

[WIP] [let_chains, 1/6] Remove hir::ExprKind::If Per #53667 (comment). r? @oli-obk

Centril mentioned this issue Apr 27, 2019

unused_parens incorrectly lints on if let true = (false && true) {} #60336

Closed

bors added a commit that referenced this issue May 10, 2019

Auto merge of #59288 - Centril:hir-if-to-match, r=oli-obk

acc7e65

[let_chains, 1/6] Remove hir::ExprKind::If Per #53667 (comment). r? @oli-obk

This was referenced May 14, 2019

Split off parts of the runtime module into input, forest and parser. rust-lang/gll#115

Merged

Add stubs to keyword docs #60817

Merged

[let_chains, 2/6] Introduce Let(..) in AST, remove IfLet + WhileLet and parse let chains #60861

Merged

est31 mentioned this issue Nov 9, 2024

Additional tests to ensure let is rejected during parsing #132828

Merged

est31 mentioned this issue Nov 10, 2024

Stabilize let chains in the 2024 edition #132833

Merged

9 tasks

paldepind mentioned this issue Nov 18, 2024

Rust: Improve CFG for let expressions github/codeql#18007

Merged

est31 mentioned this issue Nov 25, 2024

Document if/while let chains rust-lang/edition-guide#337

Merged

This comment has been minimized.

Sign in to view

landonxjames mentioned this issue Feb 10, 2025

Fix Sigv4 signing bug for endpoints with default ports smithy-lang/smithy-rs#4006

Merged

1 task

ehuss mentioned this issue Feb 25, 2025

Document let_chains again rust-lang/reference#1740

Merged

vindard added a commit to GaloyMoney/lana-bank that referenced this issue Feb 26, 2025

fix: unstable let expression

3a81572

See rust-lang/rust#53667 for more

vindard added a commit to GaloyMoney/lana-bank that referenced this issue Feb 27, 2025

fix: unstable let expression

4f64fc3

See rust-lang/rust#53667 for more

vindard added a commit to GaloyMoney/lana-bank that referenced this issue Feb 27, 2025

fix: unstable let expression

1b0b6f4

See rust-lang/rust#53667 for more

vindard added a commit to GaloyMoney/lana-bank that referenced this issue Mar 20, 2025

fix: unstable let expression

fcc017b

See rust-lang/rust#53667 for more

vindard added a commit to GaloyMoney/lana-bank that referenced this issue Mar 20, 2025

fix: unstable let expression

4482d40

See rust-lang/rust#53667 for more

vindard added a commit to GaloyMoney/lana-bank that referenced this issue Mar 20, 2025

fix: unstable let expression

3b5b8a5

See rust-lang/rust#53667 for more

calebcartwright mentioned this issue Apr 6, 2025

style guide: add let-chain rules #139456

Merged

froydnj mentioned this issue Apr 14, 2025

[prism] Support method modifier calls fables-tales/rubyfmt#541

Merged

bors closed this as completed in 8bf5a8d Apr 22, 2025

nickdrozd mentioned this issue Apr 23, 2025

Suggest using let-chains rust-lang/rust-clippy#14678

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

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

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

Centril commented Aug 24, 2018 •

edited by est31

Loading

Centril commented Mar 11, 2019

oli-obk commented Mar 11, 2019

alexreg commented Mar 11, 2019

estk commented May 20, 2019

est31 commented Nov 10, 2024 •

edited

Loading

This comment has been minimized.

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

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

Comments

Centril commented Aug 24, 2018 • edited by est31 Loading

Centril commented Mar 11, 2019

oli-obk commented Mar 11, 2019

alexreg commented Mar 11, 2019

estk commented May 20, 2019

est31 commented Nov 10, 2024 • edited Loading

This comment has been minimized.

Centril commented Aug 24, 2018 •

edited by est31

Loading

est31 commented Nov 10, 2024 •

edited

Loading