[WIP] Introduce ast::StmtKind::LetElse to allow the usage of let_else with let_chains

[c410-f3r]

Not sure if you guys will accept this PR, thus the reason of opening it early. In fact, only ./x.py check is currently working.

In order to allow "multiple local declarations" as well as different ast::Binary/ast::Let structure combinations of a let chain, LocalKind::InitElse was superseded by StmtKind::LetElse.

It was the most natural path to follow in my opinion but feel free to discuss more alternatives.

/// A `let .. && let && .. else { .. }` declaration.
#[derive(Clone, Encodable, Decodable, Debug)]
pub struct LetElse {
    pub attrs: AttrVec,
    pub expr: P<Expr>,
    pub id: NodeId,
    pub r#else: P<Block>,
    pub span: Span,
    pub tokens: Option<LazyTokenStream>,
}

pub enum StmtKind {
    /// See [`LetElse`].
    LetElse(P<LetElse>),
    ...
}

Taking aside possible Clippy and Rustfmt changes, the overall structure probably won't pass beyond AST.

cc @camsteffen
cc @matthewjasper
cc @petrochenkov

[rust-highfive]

Some changes occurred in src/tools/rustfmt.

cc @calebcartwright

Some changes occurred in src/tools/clippy.

cc @rust-lang/clippy

[rust-highfive]

r? @oli-obk

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

[rust-log-analyzer]

The job x86_64-gnu-llvm-12 failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)

   Compiling memchr v2.4.1
   Compiling std v0.0.0 (/checkout/library/std)
   Compiling compiler_builtins v0.1.66
   Compiling unwind v0.0.0 (/checkout/library/unwind)
thread 'rustc' panicked at 'non-eager expansion without a parent scope', compiler/rustc_resolve/src/macros.rs:269:22

error: internal compiler error: unexpected panic

note: the compiler unexpectedly panicked. this is a bug.
note: the compiler unexpectedly panicked. this is a bug.

note: we would appreciate a bug report: https://github.com/rust-lang/rust/issues/new?labels=C-bug%2C+I-ICE%2C+T-compiler&template=ice.md

note: rustc 1.60.0-nightly (73840beea 2022-01-28) running on x86_64-unknown-linux-gnu

note: compiler flags: -Z unstable-options -Z macro-backtrace -Z crate-attr=doc(html_root_url="https://doc.rust-lang.org/nightly/") -Z binary-dep-depinfo -Z force-unstable-if-unmarked -C opt-level=3 -C embed-bitcode=no -C codegen-units=1 -C debuginfo=0 -C debug-assertions=on -C symbol-mangling-version=legacy -C link-args=-Wl,-z,origin -C link-args=-Wl,-rpath,$ORIGIN/../lib -C prefer-dynamic -C llvm-args=-import-instr-limit=10 -C embed-bitcode=yes --crate-type lib
note: some of the compiler flags provided by cargo are hidden

query stack during panic:
end of query stack

[camsteffen]

Another "natural evolution" is destructuring assignment + let-else. But I think in both cases it is a new language feature that should have an RFC.

[c410-f3r]

• The let_else RFC briefly predicted this let chain combination (https://github.com/rust-lang/rfcs/blob/master/text/3137-let-else.md#if-let-chains).

• Integration of if_let_guard with let_chains is already possible on master and didn't require a RFC. As such, the same can probably be also applied to let_else.

• Nightly experimentation will allow the capture of possible corner cases and enhance implementation robustness.

That said, I see this PR more as an extension of the current behavior rather than introducing new features.

[joshtriplett]

I'm not fundamentally opposed to the possibility of something like

let pat = expr
&& let pat2 = expr2
else { diverge }

assuming that we can make that readable and unambiguous.

However, I don't think we want to go this route until we have an RFC or similar describing the exact syntax to be allowed, and explaining how it'll be unambiguous (including coverage of corner cases) and readable, and showing examples of real code that would improve with it.

And any such syntax would be competing with the next-best alternative of:

let pat = expr else { diverge }
let pat2 = expr2 else { diverge }

The only advantage of the combined form would be to avoid repeating a complex diverge, and I'm hoping that in the common case diverge isn't complex. So, I think there would be a higher burden of proof for the benefits of chained let-else than for a single let-else.

[joshtriplett]

Since this needs an RFC, I'm going to close it for now, but that shouldn't be taken as opposition to the idea, just that it needs an RFC prior to an implementation.