Go-to-definition not working in recursive function definitions

[rodinaarssen]

Describe the bug

Go-to-definition does not work for recursive function definitions

Desktop (please complete the following information):

• VS Code 0.13.1

[toinehartman]

Perhaps this is related to #2176

[DavyLandman]

can we confirm that it's wrong in the tmodel? if not, this should move to the rascal-language-server repo.

[toinehartman]

I remember running into this before, being an issue of VS Code, where go-to-def does not allow jumping to a surrounding range. That would explain #2176 as well.

[DavyLandman]

So I've just looked at the TModel, for this input:

lexical Y = X | "1";
lexical X = X | "1";


int fib(int n) = n <= 1 ? n : (fib(n - 1) + fib(n -2));

int x = fib(2) + fib(4);

And:

1. 1st use of X points to |rascal+lexical:///lang/bird/Test/X$c9f0b06c23b66ae9| (jumping doesn't work)
2. def of X points to |rascal+lexical:///lang/bird/Test/X$c9f0b06c23b66ae9| (jumping doesn't work)
3. 2nd use of X points to |rascal+lexical:///lang/bird/Test/X$c9f0b06c23b66ae9| (jumping in the IDE also works for this one)

the loc |rascal+lexical:///lang/bird/Test/X$c9f0b06c23b66ae9| points to |...Test.rsc|(49,20,<4,0>,<4,20>) aka the whole line with the lexical X = X | "1"; on it.

same story for fib.

So I agree with @toinehartman this is at least partially VS Code issue, where because we include the body of the function as part of the "definition"/"location" for a function (or a symbol) we return a range of the definition that includes the original cursor position. So it doesn't jump to it.

[PaulKlint]

This is an older issue that has been observed in several disguises. The root cause is that the Define as we currently have it in typepal contains (amongst others):

• the name of the defined entity as a string, here "f".
• the complete declaration of the entity as source location, here the whole declaration of f.

However, it does not contain the precise source location of the defined identifier.

As a result (in the above example):

• the use of f points to the complete declaration of f.
• VSCode refuses to jump to that location since it contains the use location of f.

The principled solution for this is to include this precise information about the declared name in the TModels for Rascal. Not a completely trivial project, but doable. Maybe the time has arrived to work on this...

[jurgenvinju]

As a workaround the Summary computation could maybe change the target location of the reference to the first character of the definition? Without ever looking into the parse tree again? The summary is exclusively used for UI so it wouldn't break anything downstream.

[toinehartman]

We ran into the need to find the location of the name of a definition while developing the rename framework as well. That uses the following solution.

https://github.com/usethesource/typepal/blob/00e4658c8268b68eb3fd3208aa1cb90b0b6efe9e/src/analysis/typepal/refactor/Rename.rsc#L430-L437

We could consider applying something similar during summary computation as well.