Incorrect fix for to_string_in_format_args

[nyurik]

I just discovered another bug in the format args parser FormatArgsExpn::parse while creating more tests for #9233.

Add this test case to the tests/ui/format_args.rs main() to see it fail:

print!("error: something failed at {}", (Location::caller().to_string()));
//                                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^  (does not include parens)

The resulting format_args.args[0].param.value has a span does NOT include the surrounding parenthesis, which means that it suggest this:

Auto-fix is incorrectly suggesting this:

error: `to_string` applied to a type that implements `Display` in `print!` args
  --> $DIR/format_args.rs:86:64
   |
LL |     print!("error: something failed at {}", (Location::caller().to_string()));
   |                                                                ^^^^^^^^^^^^^ help: remove this

which results in an incompilabre

print!("error: something failed at {}", (Location::caller());  // <-- missing closing parenthesis

cc: @Alexendoo

[Alexendoo]

This is unrelated to format_args parsing, the expression does include the parenthesis

[nyurik]

@Alexendoo why do you think that? In these examples of uninlined-format-args test that also fails, just like the format-args lint, the captured arg is clearly not including the surrounding parens - and that's why when it uses expand_past_previous_comma(), it is dis-balanced - on the left side it includes all the non-captured parens plus the comma, whereas on the right side it stays where the parsing captured it, without the closing paren.

See the build results in https://github.com/rust-lang/rust-clippy/pull/9548/checks

[Alexendoo]

Haven't looked into that one but looks like a different issue. For this it's because the parenthesis are part of the expression's span, when it does

rust-clippy/clippy_lints/src/format_args.rs

Line 270 in 5825ae7

value.span.with_lo(receiver.span.hi()),

it's including the closing parenthesis in the thing it's suggesting to remove

[nyurik]

Thanks @Alexendoo, you are right uninlined_format_args issue was due to a bug that I now have a PR for: #9588

As for the current issue in the to_string_in_format_args:

For the test case, I think I figured it out thanks to your help! See #9590. Sorry to step on your toes on this one.

[nyurik]

@rustbot claim