Type hint popup is misplaced in macros

[0x7CFE]

tldr:

Note the beam cursor is placed on e near the end of the line, inside the format! macro. Also note the type popup is placed as if I've just hovered the closure's formal parameter e: Error.

It gets even weirder if line breaks are present:

commit 856e4ba126ae776753f38c00593c02c4f43be510 (HEAD -> master, origin/staging, origin/master, origin/HEAD)
Merge: 9006cec49 f08297983
Author: bors[bot] <26634292+bors[bot]@users.noreply.github.com>
Date:   Sun Feb 2 14:05:23 2020 +0000

    Merge #2979

P.S.: 3000 get! 😋

[0x7CFE]

Looks like the issue still exist in recent builds (a regression?).

Cursor is placed on mem inside println! macro, but the type hint popped up waaaay above and to the left (see the second line):

commit 2cbe8a4c4be2a69b27c248ab96341c2336f983cd
Merge: 7836720f2 5a6e770f9
Author: bors[bot] <26634292+bors[bot]@users.noreply.github.com>
Date:   Sat Feb 22 12:31:30 2020 +0000

    Merge #3263

[edwin0cheng]

Um... it is because println! is a recursive macro, and unfortunately the original_range function used in #3228 do not support recursive macro.

https://github.com/rust-analyzer/rust-analyzer/blob/ff2d77bde6acffc5e4c42878606b3d6d92300e11/crates/ra_ide/src/expand.rs#L37

I will fix it in these days. Thanks for your report !

[edwin0cheng]

Since #3314 is merged, @0x7CFE Would you mind to test it again?

[0x7CFE]

@edwin0cheng, I've just built revision 2dee077 from the repo and it works… kinda 😅

Original issue was fixed, indeed 🎉. However, I found yet another way to break popup placement:

I placed mouse pointer to format literal of the println! macro and again, type hint popup is somewhere midway to the stratosphere.

P.S.: It seems that popup text corresponds with return type of the whole macro. So, for println! it yields (), whereas for write! it's Result<(), Error>.

[edwin0cheng]

Thanks @0x7CFE, I think I know what happened here, submit a PR to fix it (kinda).

[0x7CFE]

Thanks @0x7CFE, I think I know what happened here, submit a PR to fix it (kinda).

Unfortunately, as of revision 913cdce it still fails. All symptoms remained the same.

[edwin0cheng]

Ah... that PR fixed #3135 case, but this one is a little bit complicated.
The problem here seem to be related to println used a bulitin macro format_args_nl, which currently just a fake implementation and it returns an empty string and do not support macro token mapping.

A proper error recovery handling will be needed to fix this bug...

[edwin0cheng]

Update: #3350 ignore hover on token inside bulitin macro such that it should be fixed. I tested the following case and it works (no hover popup)

println("he<|>llo", 1);