[Semantic API] Should we include a back reference to the associated type def from a type reference?

[pubudu91]

In the semantic API, the TypeReferenceTypeSymbol corresponds to the type-reference type descriptor. As the spec states, this is basically a reference to a type defined using a type definition statement. From the TypeReferenceTypeSymbol you can get the type name and the type descriptor for which that name is bound, and the location of the type def symbol. Currently we don't have a direct reference to the associated type def symbol. But if one needs the associated type def, one can use the location and look it up using the symbol() method. Is this enough? Or should we consider adding a reference to the associated type def?

The following issue is one such case where the user needs access to the type def symbol: #27804

[nadeeshaan]

I feel like we need this. Say we are going to use the symbol() API to retrieve the TypeDef symbol will not be an effective usage if we are going to use it multiple times within a given flow. And we cannot always ensure that we have the location information to retrieve these information.

[pubudu91]

There's a location() method in TypeReferenceTypeSymbol. Can use the location returned by it to lookup. But yeah, my concern is also the performance, if we have to keep looking it up.

[rdhananjaya]

When do we retrieve the referenced type def? Is it only when user perform some action like ctrl+click or something, or is it to retrieve this information as an intermediate step to perform some other action (preferably some frequently occurring thing). If it's the first case, I think there will be almost no notable overhead by just looking it up again. But if it's an intermediate thing, and it's occurring all the time we better provide a reference too.

[pubudu91]

So a common use case is when you want to look up the documentation of a particular type. Let's say,

# This is a type
type Foo int|float;

function test() {
    Foo f = 10;
}

Consider that you get the type descriptor for the above variable f. What you get is an instance of TypeReferenceTypeSymbol. It's basically just a reference to the type def Foo and doesn't contain the meta info (docs and annotations) of the type def. So to access them, one needs to look up the original type def itself. Currently how this can be done is by calling the location() method on the type ref and using that location to look up the original type def (since location() always returns the definition location of a symbol).

I guess this will be used for features like showing the documentation when hovering over the type name. When looking up a symbol, it basically runs a visitor. Hence the performance concern.

[pubudu91]

Had a discussion regarding this during the sprint meetings as well since this requirement again came up in #29287 as well and decided to go ahead and add an API to the type ref symbol to get the associated type definition symbol of the type ref. Will add the following method to TypeReferenceTypeSymbol:

public TypeDefinitionSymbol definition();

Additionally, with this change, should we consider returning Optional.empty() from getLocation() implementation in type ref? Since the location in type ref may be misunderstood to mean the location of the usage of the type def (especially since now there will be a way to get the associated definition symbol)?

[pubudu91]

This was added with #29626