Refactor FormatArgsExpn

[Alexendoo]

It now for each format argument {..} has:

• The Expr it points to, and how it does so (named/named inline/numbered/implicit)
• The parsed FormatSpec (format trait/fill/align/etc., the precision/width and any value they point to)
• Many spans

The caller no longer needs to pair up arguments to their value, or separately interpret the specs Exprs when it isn't None

The gist is that it combines the result of rustc_parse_format::Parser with the macro expansion itself

This unfortunately makes the code a bit longer, however we need to use both as neither have all the information we're after. rustc_parse_format doesn't have the information to resolve named arguments to their values. The macro expansion doesn't contain whether the positions are implicit/numbered/named, or the spans for format arguments

Wanted by #9233 and #8518 to be able to port the changes from #9040

Also fixes #8643, previously the format args seem to have been paired up with the wrong values somehow

changelog: [format_in_format_args]: Fix false positive due to misattributed arguments

r? @flip1995
cc @nyurik

[smoelius]

Maybe this makes #8857 unnecessary?

[flip1995]

This all is really specific to how the format_arg! macro expands. But that also was the previous code, so I don't see this as a blocker.

However, I noticed that the pattern is to construct those things from rpf information. Can you give an estimation how likely it is to add this information to rpf and give Clippy access to it? This feels like we're doing work that is/can already (be) done in rustc.

Those are no blockers. Just a few comments how the code could maybe be improved.

[flip1995]

Only 2 minor comments, then we can move on with the other PR 🚀

[Alexendoo]

However, I noticed that the pattern is to construct those things from rpf information. Can you give an estimation how likely it is to add this information to rpf and give Clippy access to it? This feels like we're doing work that is/can already (be) done in rustc.

I don't think rustc_parse_format could gain the full capabilities since it's intended to compile on stable. Resolving the names would need access to the bits (TokenTree?) that come after the format string

There is talk of making format_args its own node though, so maybe in the future we can delete all of this 😄

[flip1995]

Thanks, just another detail. After that r=me.

[flip1995]

@bors r+

Thanks!

[bors]

📌 Commit 4f049f5 has been approved by flip1995

It is now in the queue for this repository.

[bors]

⌛ Testing commit 4f049f5 with merge 3e594de...

[bors]

☀️ Test successful - checks-action_dev_test, checks-action_remark_test, checks-action_test
Approved by: flip1995
Pushing 3e594de to master...