Rustfmt changes meaning of closure, also not idempotent

[dtolnay]

Input program, which compiles:
https://play.rust-lang.org/?edition=2018&gist=046bcee6f5a6524efd1cf0d71b383fef

fn main() {
    || {
        println!();
        || 0
    }().to_string();
}

As of rustfmt 2.0.0-rc.1-nightly (b9138e0 2020-02-10), rustfmt incorrectly changes this to the following which does not compile:

fn main() {
    || {
        {
            println!();
            || 0
        }()
        .to_string()
    };
}

It is also not idempotent, since running rustfmt again changes it to:

fn main() {
    || {
        {
            println!();
            || 0
        }
        ().to_string()
    };
}

[rchaser53]

This issue is also caused v1.4.12

[topecongiro]

I don't know why the first code compiles successfully in the first place, though either way, rustfmt not being idempotent is a problem.

[topecongiro]

This code snippet compiles as well:

fn main() {
    || {
        println!();
        |_| 0
    }(())
    .to_string();
}

This behavior indicates that the rustc parser considers the paren after the block as an argument to the closure inside the block. Weird!

[davidBar-On]

This behavior indicates that the rustc parser considers the paren after the block as an argument to the closure inside the block. Weird!

I tried to evaluate this issue, but I am not sure what exactly the code means. As indicated by the above comment, it seems as an anonymous-function inside anonymous-function. E.g. the output of:

    let a = 5;
    let b = 7;
    let b2 = || { |x|  x + 2 }(b);
    let b = 8;
    println!("a+1={}, b+2={}, b={}", add1()(a), b2(), b);

is a+1=6, b+2=9, b=8.

Is the interpretation of "anonymous-function inside anonymous-function" correct?

[ytmimi]

confirming this is reproducible with rustfmt 1.5.1-nightly (a451a39d 2022-07-25)