Incorrect named_arguments_used_positionally suggestion in obscure case

[nyurik]

This code is not really something anyone SHOULD write, but because rustc catches it and makes a suggestion, it should either handle it correctly, or not suggest anything at all and give a different warning because it is clearly not something anyone should ever write, and thus it is likely a bug.

    let val = 5;
    // same issue for all these cases
    println!("{:0$}", v = val);
    println!("{0:0$}", v = val);
    println!("{:0$.0$}", v = val);
    println!("{0:0$.0$}", v = val);
    // these work correctly, but should probably give a different warning (see below)
    println!("{0:0$.v$}", v = val);
    println!("{0:v$.0$}", v = val);
    println!("{v:0$.0$}", v = val);
    println!("{v:v$.0$}", v = val);
    println!("{v:0$.v$}", v = val);
    println!("{v:v$.v$}", v = val);

Expected

I expected to see this happen (one of these):

• suggest corrected version

62 |     println!("{v:v$}", v = val);

• ignore it as part of named_arguments_used_positionally, but warn as part of some new warning like argument_used_multiple_times_as_value_and_as_format_or_precision (the name needs some work :) )

Current behavior

Instead, rustc showed this incorrect suggestion:

warning: named argument `v` is not used by name
  --> src/main.rs:64:23
   |
64 |     println!("{:0$}", v = val);
   |               -----   ^ this named argument is only referred to by position in formatting string
   |               |
   |               this formatting argument uses named argument `v` by position
   |
   = note: `#[warn(named_arguments_used_positionally)]` on by default
help: use the named argument by name to avoid ambiguity
   |
64 |     println!("{v}", v = val);
   |               ~~~

Meta

rustc --version --verbose:

cargo 1.64.0-nightly (d8d30a753 2022-07-19)
release: 1.64.0-nightly
commit-hash: d8d30a75376f78bb0fabe3d28ee9d87aa8035309
commit-date: 2022-07-19
host: x86_64-unknown-linux-gnu
libgit2: 1.4.2 (sys:0.14.2 vendored)
libcurl: 7.83.1-DEV (sys:0.4.55+curl-7.83.1 vendored ssl:OpenSSL/1.1.1n)
os: Linux Mint 20.3 (una) [64-bit]

[compiler-errors]

I think @PrestonFrom is working on this?

[PrestonFrom]

Yea, I am! Sorry, taking a little longer than I expected.

Thank you for the additional test cases!

[compiler-errors]

No rush @PrestonFrom.

[nyurik]

@PrestonFrom awesome! I have been hacking on rust-lang/rust-clippy#9233 -- a clippy lint to inline print!("{}", var) into print!("{var}"), and there are a lot more test cases including two that broke rustc up until a few days ago (note that that PR is based on another PR, so the actual change is much smaller). It seems the current internal clippy code for the format arg parsing is a bit lacking - it doesn't track precision and width argument spans, nor can it detect if an argument is being used (aliased) by width/precision in addition to the value use. I wonder if there should be some code reuse between the projects. Currently it is all in FormatArgsArg and related.

Thanks @compiler-errors for the connection!

[compiler-errors]

It seems the current internal clippy code for the format arg parsing is a bit lacking - it doesn't track precision and width argument spans

Lol, yeah the current implementation in rustc doesn't track these spans either. 🤣

[compiler-errors]

@PrestonFrom did you fix this or does this need to further fixed? (Just asking, no pressure for you to do it if it's not fixed by your previous PRs)

[PrestonFrom]

@compiler-errors Oh, sorry! I believe this is fixed by previous PRs.

[compiler-errors]

No worries. Just trawling the issues backlog 😄

[PrestonFrom]

Just checked and unless I'm mistaken all the cases in this issue are covered.

Is it okay to close this?