Handle constant aliases and ability to follow them

[vinistock]

Motivation

Closes #916

First step for #908

We need to handle constant aliases properly, so that we can provide go to definition, completion and hover for them.

I'd appreciate feedback on the proposed API here.

Implementation

The idea of the implementation is the following:

• When we find a constant alias, there's a chance we haven't indexed the target constant yet, so we can't eagerly try to resolve it
• Instead, we place UnresolvedAlias entries in the index, which remember the target name and the nesting where the alias was found
• Then, I'm proposing the addition of follow_alias, which does two things:
  • Turns UnresolvedAlias entries into a concrete Alias. This is done by taking the target and nesting and then resolving to what target the alias refers to, since at this point we finished indexing
  • Then we loop through all of the concrete aliases to figure out which constant the alias ultimately points to (since Ruby allows you to have an alias that points to another alias)

Automated Tests

Added tests that show the behaviour of the proposed API.

[Morriar]

It's a lot of parameters, I wonder if we should use keywords instead? It may require some refactoring.

[vinistock]

Let's do the refactor in a different PR, since it will require quite a few changes.

[Morriar]

Since the alias is "resolved", why not having it pointing to the constant directly? It would make following the aliases easier.

[vinistock]

Because we may have multiple entries for the same name. Having the resolved fully qualified name allows us to fetch those entries that are stored in the index.

[andyw8]

Suggested change

	original_entries = T.must(@entries[entry.name])
	original_entries = @entries.fetch(entry.name)

[vinistock]

I'm really not a fan of that style, to be honest.

[vinistock]

Okay, I finally was able to realize what was missing for properly following aliases. When we are trying to resolve a name including namespaces, we need to recursively try to resolve possible aliases in the namespace to find the actual target.

So, if we take this alias from the Ruby LSP itself, this is the behavior now:

module RubyLsp
  Interface = LanguageServer::Protocol::Interface
end

# If we have a reference to `Interface`, then this will return the alias entry, allowing
# us to jump to the alias declaration
@index.resolve("Interface", ["RubyLsp"])
# => "RubyLsp::Interface"

# If we are reaching inside the aliased namespace, then we'll recursively resolved aliases
# along the name to ensure that we land on the right place. For example, for
# `Interface::Location`, we get
@index.resolve("Interface::Location", ["RubyLsp"])
# => "LanguageServer::Protocol::Interface::Location"

I believe this implementation makes sense. When there's an alias, the constant really exists so we can jump directly to it. When we are accessing inside an aliased namespace, then RubyLsp::Interface::Location indeed doesn't exist, it's the resolved alias (LanguageServer::Protocol::Interface::Location) that exists.

This PR already gets definition and hover working for aliases. After this goes in, I'll handle completion, which requires some extra work.

[vinistock]

Okay, I fixed one remaining issue with following aliases. I think this should be good to review now.

[Morriar]

Are we missing the handling of constant target nodes? A, B = 42 and FOO::A, FOO::B = 42?

[vinistock]

We are indeed. Can I follow up with a separate PR for that? It will require some special handling because we need to take a look at the right hand side to figure out if they are aliases too.

So, we'll need to handle MultiWriteNode and the constant target nodes inside. I can create a PR immediately after this one.

[vinistock]

#1034