Find all references and go to definition for type and lifetime parameters

[djrenren]

It would be nice to be able to perform these operations. Specifically Find all references is helpful on structs and traits where it's not-obvious how the parameter is going to be used at declaration time.

[djrenren]

I'd be willing to take a crack at this, but I'm still learning the codebase.
I think the issue is that we're not indexing the references from Type and Lifetime parameter use-sites. If this is indeed the problem, could someone point me to where that would need to happen in the codebase. Thanks!

[matklad]

Awesome, @djrenren!

So in general symbol search in IDEs work like this:

• iterate all potential references
• resolve each reference and check if it indeed resolves to the source definition

That is, IDE does not maintain a persistent use-def index.

For lifetime and type parameters the "all potential references" set is easy to define: they can only be used inside the item which defines them.

However, I don't think we actually handle "resolve" bit yet. Specifically, for something like

struct S<Quuux> {
    t: Quuux
}

we can't yet see that Quuux in t: Quuux is the same as in S<Quuux>. That needs to be fixed first....

Aha, I see, we actually handle that, it's just not exposed via goto defenition UI:

https://github.com/rust-analyzer/rust-analyzer/blob/592b906604d60a86af74c5dbb3bf40b2ddcf8061/crates/ra_ide_api/src/goto_definition.rs#L121

@djrenren what would you think about fixing ^ first? It's an easier issue which should make you more familiar with name-resolution infrastructure we currently have.

[matklad]

Specifically, that fragment of code is tasked with turning an IR-level representation of name resolution back into source-level one. Looking at how this is is done for local variables is helpful:

https://github.com/rust-analyzer/rust-analyzer/blob/592b906604d60a86af74c5dbb3bf40b2ddcf8061/crates/ra_ide_api/src/goto_definition.rs#L111-L117

Basically, we use an integer id in IR, and store a separate source-map, which maps id back to syntax.

The similar infrastructure should be implemented for generic parameters.

[djrenren]

Wow there's a lot of infrastructure behind those lines, but I think I'm getting a handle on it.

Do we still want to construct that full mapping in the style of BodySyntaxMapping, or is it sufficient to just bubble up the items. Because type parameters can only be introduced on items, it seems like we could do something much simpler.

But for starters? How do I start doing anything with syntax, because everything in scope seems to be talking about IR. Is that mapping fundamentally in the db?

[matklad]

@djrenren let's talk this through on Zulip perhaps? https://rust-lang.zulipchat.com/#narrow/stream/185405-t-compiler.2Fwg-rls-2.2E0/topic/rust-analyzer.23907

[matklad]

How do I start doing anything with syntax,

Here's a useful API walkthrough: https://github.com/rust-analyzer/rust-analyzer/blob/00b09bcd8c96c37633964aa40df711dc013a6ca5/crates/ra_syntax/src/lib.rs#L96

Because type parameters can only be introduced on items, it seems like we could do something much simpler.

Yeah, I think GenericDef should own GenericsSourceMap

[Geobert]

Hi there!
Out of curiosity, did any work been done on this topic?
It's the big missing one for me compared to RLS ^^

[matklad]

No, this still isn't implemented

[Geobert]

I'm hoping to free some time to pour into rust-analyzer, maybe one day I'll gather enough knowledge on this project to tackle this. I'll keep you guys posted :)

[matklad]

Type parameters part of this is handled by #2494

[lnicola]

This was also implemented for lifetimes: #6907 and a couple of follow-ups.