RustFmt fails to format file with long line within scope of lambda passed to member function

[VeaaC]

fn f() {
    something.do_stuff(|| {
                {
                    "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
                }
            }   );
}

I tried to reduce it more, but any change caused it to work again.

[Elarnon]

I hit this today, so here is another example with more info. Notes from my experiments:

• Rustfmt only fails to format the block containing the long line
• There needs to be a method call. If calling bar(..) instead of foo.bar(..) things work as expected. Using Foo::bar is a workaround.
• There needs to be a block inside the method call (so you need foo.bar({ .. }), not just foo.bar(..)).
• The "long token" doesn't need to be a string, but it needs to be inside some other expression. Curly brackets {xxx} or a function call f(xxx) both trigger the bug; a tuple (xxx, ) does not.

fn main() {
    rustfmt.will(properly + reformat).this();
    foo.bar({
rustfmt        .
will(NOT
+
touch
                        )
.this()
;
{"xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"}
    });
}

Edit: By "Using Foo::bar is a workaround", I mean that you can get the right formatting by temporarily using foo::bar instead of foo.bar, running rustfmt, then reverting back to foo.bar. Since rustfmt won't touch the code in the foo.bar case you get to keep the good formatting even after changing back to foo.bar.

[nrc]

There is no good formatting here because the string lit is too long for the max width. SO I think in this case, doing nothing and let the user fix it is the right thing to do.

[VeaaC]

I would agree about the line in question, but it breaks all the blocks it is in, e.g. in my use case a few hundred lines, and without indication which line is responsible.

Also: It also breaks if the long line consists of symbols that are possible to line-break properly (e.g. I had a longer macro invocation in there, not a long string)

[scampi]

@VeaaC Can you share an example of that long line with a macro ? thanks!

[scampi]

@Elarnon do you have an example of the following ? I tried to replace the curly brackets around the long string from your comment with a tuple but it didn't get formatted either.

The "long token" doesn't need to be a string, but it needs to be inside some other expression. Curly brackets {xxx} or a function call f(xxx) both trigger the bug; a tuple (xxx, ) does not.

[Elarnon]

@scampi Indeed, I checked again and it does trigger the bug as well. I think I got confused because the behavior around tuples and whitespaces is really weird:

fn main() {
    foo.bar({
underindented();
{(  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx,)}
    });
}

triggers the bug, but if you do any of the following, it no longer triggers:

• Remove one x
• Remove one space before the xs
• Remove the comma
• Replace the comma with an x
• Put the spaces before the opening paren ({ (x...).

BTW I will reiterate that rustfmt works properly with :: instead of .:

fn main() {
    foo::bar({
underindented();
{"xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"}
    });
}

gets formatted into

fn main() {
    foo::bar({
        underindented();
        {
            "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
        }
    });
}

which is arguably the "least bad formatting", even if no "good" ones exist.

[VeaaC]

This one fails to split a macro (instead of the long string):

fn f() {
    something.do_stuff
    (
    |
    | 
    {
        error!(context.logger, "metric_production_abcdefgere"; "reason_abcdefg" => format!("{}", e));
    }
    );
}

Making the line any shorter will format the rest of the code normally, but still not split the macro:

fn f() {
    something.do_stuff(|| {
        error!(context.logger, "metric_production_abcdefgere"; "reason_abcde" => format!("{}", e));
    });
}

[shepmaster]

Is this the same root cause?

fn x() {
    let near : Vec<u8> = foo("xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx");
}

Rustfmt 1.0.0-nightly (2018-11-30 43206f4) reports no errors or warnings, the exit code is zero, and the file is not changed:

$ cat original
fn x() {
    let near : Vec<u8> = foo("xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx");
}
$ cp original fmt
$ rustup run nightly rustfmt fmt
$ echo $?
0
$ diff original fmt
$ rustup run nightly rustfmt --version
rustfmt 1.0.0-nightly (43206f41 2018-11-30)

[shika-blyat]

I faced this issue today, and it tooks me 5 hours to understand the problem was coming from my string which was too long, but rustfmt gave me no warning nor error.
Considering adding a warning/an hard error for such cases instead would be feasible ?