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

[Centril]

This is a tracking issue for the eRFC "if- and while-let-chains, take 2" (rust-lang/rfcs#2497).
For the tracking issue for the immediate edition changes, see #53668.

Steps:

• Implement the RFC (cc @rust-lang/compiler -- can anyone write up mentoring instructions?)
• Adjust documentation (see instructions on forge)
• Formatting for new syntax has been added to the Style Guide (nightly-style-procedure)
• resolve expr fragment specifier issue (#86730)
• Initial stabilization PR: Stabilize let_chains in Rust 1.64 #94927, reverted in Revert let_chains stabilization #100538
• Second stabilization PR: Stabilize let chains in the 2024 edition #132833

Unresolved questions:

• The final syntax
  • This would benefit from a design note summarizing previous discussions on let as a boolean expression, and possibilities of is syntax.
• Should temporary and irrefutable lets without patterns be allowed in some form?
• Chained if lets inside match arms

Collected issues:

• unused_parens incorrectly lints on if let true = (false && true) {} #60336
• Cleanup hack to expect scrutinee: bool in if-to-match desugaring in match-expr typeck #60707
• Deduplicate diagnostics in if-without-else-as-fn-expr.rs #60254
• MIR building for match $c { true => $i, _ => $e } is slow #60571
• Suggest if let when a failed if block could be parsed as one #44990

Implementation history:

• Run branch cleanup after copy prop #59290
• Generalize diagnostic for x = y where bool is the expected type #59439
• Introduce hir::ExprKind::Use and employ in for loop desugaring. #60225
• [let_chains, 1/6] Remove hir::ExprKind::If #59288
• [let_chains, 2/6] Introduce Let(..) in AST, remove IfLet + WhileLet and parse let chains #60861
• [let_chains, 3/6] And then there was only Loop #61988
• Reintroduce hir::ExprKind::If #79328
• Introduce hir::ExprKind::Let - Take 2 #80357
• Lower condition of if expression before it's "then" block #82308
• Formally implement let chains #88642
• Add tests to ensure that let_chains works with if_let_guard #93086
• Fix let_chains and if_let_guard feature flags #93213
• [rustc_parse] Forbid lets in certain places #97295
• Warn users about || in let chain expressions #94754
• Ensure that let_else does not interact with let_chains #94974
• [let_chains] Forbid let inside parentheses #95008
• Tell users that || operators are not currently supported in let chain expressions #95314

Unresolved problems

• Can we be confident that the implementation is correct and well tested?

[Centril]

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

[oli-obk]

for the record, the discussed step list is

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

[alexreg]

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

[estk]

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

[traviscross]

We talked about this in the lang planning meeting today. As far as we know, the blockers and semi-blockers to this have been resolved. E.g.:

• Tracking Issue for updating expr macro fragment specifier for Rust 2024 #123742
• Tracking Issue for Rust 2024: Rescope temporary lifetimes with respect to else #124085

At this point, we would encourage someone to write up a comprehensive stabilization report and include that in a PR proposing let-chains for stabilization. We're looking forward to considering that proposal.

[est31]

This is really wonderful news, @traviscross! I've went over the original stabilization PR (now reverted) and related issues to refresh my memory. I've found two possible stabilization blockers that I have opened zulip threads about.

• syntactic rejection is maybe not complete?
• formatting stabilization: from how I read this document, nightly syntax formatting needs to be stabilized and formalized. We have formatting present in rustfmt but is it also formalized?
• I don't see anything that should be a stabilization blocker with the F-let_chains label at this point

As there is many people subscribed, please try to keep replies in the linked zulip threads.

[est31]

Stabilization report/PR: #132833