Implement missing functionality for call hierarchy API

[colin-grant-work]

What it does

Fixes #9612 by implementing the commands used by the vscode-references-view plugin to retrieve call hierarchy information.
It also:

• Deprecates the CurrentEditorAccess class in the call-hierarchy package in favor of the one implemented in the editor package.
• Fixes a bunch of off-by-one translation errors between RPC Model Ranges and VSCode Ranges. That is an absolute mess that deserves separate treatment. The translation is implemented separately at least 5 times.
  • Fixes showTextDocument is not compatible to vscode and assumes non zero-based range #7065
  • Fixes vscode.open does not accept vscode.Selection as a selection option #8333
• Adds a check to Timeline module to ensure that a selection exists to avoid an error log that appeared in the original issue report but wasn't actually the cause of the failure of the call hierarchy code.

How to test

1. You should be able to use the Calls: Show Call Hierarchy Command
2. You should be able to get both incoming (default) and outgoing calls.
3. When you click on a node, it should reveal the location of that function. Confirm that your cursor is at the beginning of the function.

Review checklist

• as an author, I have thoroughly tested my changes and carefully followed the review guidelines

Reminder for reviewers

• as a reviewer, I agree to behave in accordance with the review guidelines

Signed-off-by: Colin Grant colin.grant@ericsson.com

[colin-grant-work]

Strictly speaking, this isn't necessary to get the version of the plugin downloaded by our scripts to work because it uses vscode.window.showTextDocument rather than this command. However, later versions of the plugin use the vscode.open command, and we have an off-by-one issue when handling TextDocumentShowOptions passed by plugins into that command.

[RomanNikitenko]

@colin-grant-work
I see that you picked up the latest changes from the master - just fyi - some tests will fail due to #9692, so such failure is not related to your changes

[colin-grant-work]

... some tests will fail due to #9692, so such failure is not related to your changes

Thanks for the heads up. Always nice to have someone else to blame 🙂

[RomanNikitenko]

@colin-grant-work
I'm going to test/review the changes tomorrow.
I'm sorry for the delay...

[RomanNikitenko]

I tested a little the changes and can confirm that in general it works well for me!

I noticed that the source is not displayed for items:

VS Code:

Theia:

Another difference which I found:
VS Code moves cursor to the corresponding method when I use double click, but Theia does nothing for me.

VS Code

Theia

@colin-grant-work
Does it work for you?

I'm not requesting a fix - I think we can improve it in a separate PR - just sharing what I detected within review the PR...

[RomanNikitenko]

@colin-grant-work

Confirm that your cursor is at the beginning of the function.

What do you mean?
I don't see that my cursor moves to a function. Should it work at double click?
maybe I'm doing something wrong...

[colin-grant-work]

I noticed that the source is not displayed for items

Good find. I'm not sure what's going on here - I'll check how that data is specified in the tree items created by the plugin and how we're handling them.

Another difference which I found:
VS Code moves cursor to the corresponding method when I use double click, but Theia does nothing for me.

@colin-grant-work
Does it work for you?

It does work... sort of. I think the difference here is that VSCode transfers focus to the editor on double click, so you can see your cursor, but Theia transfers focus back to the reference view, so the editor cursor disappears. If you click the editor tab to focus the editor, the cursor should be in the same place in Theia as it is in VSCode. I recall seeing code with something like preserveFocus: true, so I'll check whether that's on our side or the plugin's, and whether it's an appropriate choice for all situations.

[colin-grant-work]

@RomanNikitenko, I think that what you're seeing in VSCode may be a fairly recent addition or depend on other functionality. Running VSCode 1.50 in the same environment as I run Theia, here's what I see:

And when double clicking to open the reference, focus stays in the references widget (orange/brown is the focus color for the tree, and no cursor is present in the editor):

If you activate the editor, the cursor should be at the beginning of the function that calls the function you're interested in. The plugin is passing preserveFocus true to the document opener, so I believe that that behavior is correct.

Running the most recent VSCode, I get the behavior you describe, but the version of the plugin that we're using is quite old (0.0.47 vs current 0.0.80), so I think we shouldn't expect to see the exact same behavior in the two contexts.

[RomanNikitenko]

@colin-grant-work

@RomanNikitenko, I think that what you're seeing in VSCode may be a fairly recent addition or depend on other functionality.

thank you for the investigation and detailed explanation!

[RomanNikitenko]

@colin-grant-work
btw: your PR fixes #8333
at least vscode.open command

[colin-grant-work]

@colin-grant-work
btw: your PR fixes #8333
at least vscode.open command

Thanks for pointing that out. I'll check the diff command, and if it's as straightforward to fix as vscode.open, I'll add it to this PR.

[colin-grant-work]

Thanks for pointing that out. I'll check the diff command, and if it's as straightforward to fix as vscode.open, I'll add it to this PR.

Adding vscode.diff to the list of known commands resulted in the same behavior as #8334. I've created an issue (#9746) for the odd behavior of the diff widget on opening, which I believe to be a separate problem.

[colin-grant-work]

I'll merge this tomorrow if there are no objections, to leave some time before the release.