feat: Support for GOTO def from *inside* files included with include! macro

[wasd96040501]

close #14937
Try to implement goto def from inside files included with include! macro.
This implementation has two limitations:

1. Only one file which calls include! will be tracked. (I think multiple file be included is a rare case and we may let it go for now)
2. Mapping token from included file to macro call file (semantics.rs:646~658) works fine but I am not sure is this the correct way to implement.

[cmyr]

Thanks for looking into this! I've played around with it a bit in a test project, where it's working fine, and also in my real project where I haven't been able to get it to work. (edit: after clearing some caches and restarting again it looks like it's working here too!)

Can you clarify what you mean by "Only one file which calls include! will be tracked."? Does this mean that we only track only track one include! for a given target file, or do you mean something else (like in a given project, only a single file can have include! statements that are tracked?)

In my test project it looks like this is working for multiple includes (e.g. A includes A' and B includes B' and I can navigate from both the included files.)

If you're curious to see the original project that motivated this issue it's available https://github.com/googlefonts/fontations/; specifically both the read-fonts and write-fonts crates use a pattern where there is a generated/ folder containing a bunch of code that is included from corresponding files in the src/tables directory.

[wasd96040501]

@cmyr Thanks for your positive feedback!
"Only one file which calls include! will be tracked." means, for example, a file A is included both by B and C, the navigation in A will respect to only one of B and C.
Here is a simple code
file A.rs

fn eat() {
    apple();
}

file B.rs

fn apple() {
}
include!("A.rs");

file C.rs

fn apple() {
}
include!("A.rs");

When we goto def in apple() of A, we will only navigate to one of B and C, not both.

[cmyr]

okay yes I think that is an intuitive and reasonable restriction that A) indicates that the user probably has more serious problems and B) I forget what I was going to say for B).

For what it's worth I would probably phrase this as, "A given file can only be tracked via include! to a single location." Or something, I found the original phrasing a bit ambiguous.

Ultimately unimportant nitpicking though, thank you for the patch, this will significantly improve our quality of life. :)

[Veykril]

Thanks!
Only supporting a file once per include is fine, we can fix that rather easily but I don't think we gain much from that right now.

The mapping logic looks correct to me.

The main issue here is that non-item level includes won't work with this, but this was known from the start given the lazy nature of rust-analyzer so that will most likely never work.

@bors r+

[bors]

📌 Commit b22e772 has been approved by Veykril

It is now in the queue for this repository.

[bors]

⌛ Testing commit b22e772 with merge 22b6f96...

[bors]

☀️ Test successful - checks-actions
Approved by: Veykril
Pushing 22b6f96 to master...