Reference resolution in errors

[MeAmAnUsername]

Short description
Allow CTRL + click on a function or variable name in errors to go to the declaration of that name or variable

Problem description.
Current process to debug an error: look at error in the eclipse Problems View, (optionally copy to text file for easier reading), decide which of the functions / variables to look into, manually navigate to the position in the source code (either by knowing where it is or searching for the function name).

Describe the solution you'd like
Reference resolution from function names / variables in errors in stxresult files and the Eclipse error view to their declaration in stxtest or stx files, such that I can CTRL+click (Command+click on Mac) on a name to go to the declaration immediately.
If a variable or function is generated by Statix, it should refer to the constraint or function that generated it.
Note that there are four locations where I would like this reference resolution:

1. In stxresult files (perhaps possible after Navigation in Test Results #85, although depending on the implementation it will require cross-language reference resolution)
2. In errors shown in programs when hovering over the error (probably impossible without changes to Eclipse)
3. In errors shown in the Problems View (probably impossible without changes to Eclipse)
4. In unnamed files (will be hard, but might be possible. Requires some changes to how Spoofax works, and also cross-language reference resolution)

Either one of 2, 3 or 4 would be enough to go to definition for errors in programs.

Describe alternatives you've considered
As is noted in the solution, getting this to work for programs will likely be a lot of work. An alternative solution for 3 is to implement a custom Problems View where we can parse and analyze the errors. This seems like one of the more feasible options, along with option 4. If we are implementing a custom error view anyway, it may be possible to include the full stacktrace and terms in errors, but to collapse them if they become too big, with the option of clicking to unfold it.

Note
Right now I don't feel like this is that useful, especially given how much work it will be to implement this. However, I felt the same about reference resolution in scope graphs, and that turned out to be extremely convenient.

[AZWN]

Although I like the principle of pervasive reference resolution, I doubt whether reference resolution from eclipse views will be worth this implementation effort. Double-clicking the message in the Problems View should already resolve to the message location, and from there it should be easy to navigate to definitions of involved variables/functions etc.

[MeAmAnUsername]

Double-clicking the message in the Problems View should already resolve to the message location, and from there it should be easy to navigate to definitions of involved variables/functions etc.

That is not as easy as it might seem.
Entries in the problems view are single line only, so the stacktrace is not shown at all.
Double clicking in the problems view brings me to the error location in the example program. Mousing over the error marker shows all errors at that location, but when there are multiple errors (as is often the case while working on language systems, e.g. generics) quite often that is too large to show in a simple text box (especially with stack traces enabled). Instead, it will be text box with a scroll bar. Finding the error I saw in the problems view in that text box is simple but not easy, and it is certainly frustrating. After I find the error (while not leaving the box with the mouse, at which point the box will disappear and I have to mouse over the error marker again and start searching again) I have to copy the function I want to look at and find that function (go to location by hand, use CMD+F / CTRL+H). To do that, I leave the box with my mouse and the error is gone again, when I want to look at it again I need to mouseover and scroll to it again.
Alternatively, I can copy the full text box to an unnamed file and search there. That will preserve my location and text selection, but does not update automatically (I need to re-copy the errors every time I build or change the example). Right now this is a better option than using the error box from mousing over the error marker.

I should also note that in this workflow, the error is actually a debug message (using try{false}|note$[DEBUG - ...]). To debug, I need to look at the actual values in the debug message, and the function implementation(s) in the Statix specification.
The functions I try to debug are hit multiple times, so there will be anywhere from 1 to 12 debug notes for the same function, each with slightly different values. Since they are all for the same function, only the values in the messages differ.
I am interested in one specific one of those 12, so finding the correct one requires me to look at every value in detail. Since #60 is not implemented yet, I cannot print the full type and its type arguments, so often data types are only differentiated by their scope identifiers. When I mouse out of the box, the messages disappear and I have to look it up again.

I can see how this specific use case is probably not too common. I am done working on generics, so right now even I am don't have this use case. However, when you do have many errors with stacktraces it becomes very hard to work with.

[AZWN]

I think it would be better if spoofax tried to integrate better with code navigation services IDE's provide, rather than doing such an overhaul in the Statix language. I'll talk about this with Daniel sometime.