Support format_args_capture

[tamasfe]

The format_args_capture feature seems to have been stabilized and will be enabled in 1.58.0 which is pretty soon. It would be nice to resolve the captured identifiers.

[JosephTLyons]

Auto-completion here would be fantastic!

[felipesere]

Is there some broad guidance if I wanted to work on this?

[Veykril]

The problem here is that we don't have free tokens that we can do analysis on, but jsut a string literal that may contain multiple references to things. This will require special cases in basically all places that allow interacting with local variables, so supporting this will most likely turn out rather messy.

So we either have to special case everything, which I really hope we don't have to but what I fear we will inevitable are forced to do. Or we'll have to think a bit about whether we can change some internal things in a more general way to allow this "mapping of partial spans of tokens" which we currently just can't do.

With that said I think the biggest support need here right now is probably renaming which I think we can just special case for the time being if the demand is there, with that in mind I believe the steps for that are the following:

• adjust https://github.com/rust-lang/rust-analyzer/blob/master/crates/hir-expand/src/builtin_fn_macro.rs#L234-L273 to properly extract the captures from within the format string and expand those like the rest in there. This change alone won't make any difference though, its just the simplest thing to tackle right now.

• adjust our usage searching code here https://github.com/rust-lang/rust-analyzer/blob/master/crates/ide-db/src/search.rs#L436-L540 to also look for ast::String literals containing the locals if we are in fact searching for a local and then extract the corresponding ast::NameRef from the expansion of step 1 with the text range being the format specifier reference in the string literal.

• adjust this function to also look for format strings (and maybe some follow up things) in the rename code to support renaming https://github.com/rust-lang/rust-analyzer/blob/master/crates/ide/src/rename.rs#L121-L202

And finally put a big BIG reminder on those special cases that they should hopefully be temporary. With all said, this is probably a tricky one to fix, even if we only consider the special casing right now ...

[jplatte]

To clarify, it's just hovering over that part of the format string and getting info in a popover that would be very hard? If rename would be simple enough, does the same apply to making extract-to-function work on a snippet that references a given variable only through such a format string?

[Veykril]

Hover should be fairly easy to implement, just a check if we hover a string literal that is part a format_args invocation, extract the captured identifiers and check if the cursor hover pos is inside of the range of one of the identifiers. In general most are equally simple/difficult, its just that we need to special case this for basically every ide feature that interacts via tokens which is just horrible :) But necessary for the time being.

I only see us either special casing this everywhere or revamping our token map architecture which we need to rewrite anyways, though I believe if we make that text range based (which I think was the plan) we could fix this up in a better way.

[felipesere]

I've started a PR where I naively extract identifiers from the format_args.

I saw that crates/ide-db/src/syntax_helpers/format_string.rs
has most of a parser for that already built. Should be re-using that?
The fact that it was under ide-db made me doubt myself 🤷‍♂️

[jonas-schievink]

I'd really prefer to implement this on top of #9403 (which should allow mapping arbitrary spans instead of full tokens into a macro expansion) rather than special-casing implicit captures in every r-a feature