[READY] Implement LSP type/call hierarchies as actual hierarchies #1733
Conversation
|
I need to schedule some time to play with this poc |
e663097 to
dcab4b9
Compare
There was a problem hiding this comment.
Reviewable status: 1 of 2 LGTMs obtained (waiting on @bstaletic)
a discussion (no related file):
Ideally, we would also update the openapi.yaml for the docs. No need to duplicate anything that's in the LSP spec, but we maybe should document our modifications/normalisattions on our ycmd API.
There was a problem hiding this comment.
Reviewed 7 of 7 files at r3, all commit messages.
Reviewable status: 1 of 2 LGTMs obtained (waiting on @bstaletic)
e13a04a to
a4b4bdc
Compare
There was a problem hiding this comment.
Reviewed 15 of 15 files at r4, all commit messages.
Reviewable status: 1 of 2 LGTMs obtained (waiting on @bstaletic)
There was a problem hiding this comment.
This should finally be ready.
If only Microsoft had not borked windows-2022 C runtime...
Reviewable status: 1 of 2 LGTMs obtained (waiting on @puremourning)
a discussion (no related file):
Previously, puremourning (Ben Jackson) wrote…
Ideally, we would also update the openapi.yaml for the docs. No need to duplicate anything that's in the LSP spec, but we maybe should document our modifications/normalisattions on our ycmd API.
Done.
There was a problem hiding this comment.
Reviewable status: 0 of 2 LGTMs obtained (and 1 stale) (waiting on @bstaletic)
ycmd/completers/language_server/language_server_completer.py line 3413 at r5 (raw file):
file_contents = [] range = location.get( 'selectionRange' ) or location[ 'range' ]
I think this might be surprising when used in other contexts. There are other request that have 'selectionRange' , such as "DocumentSymbol" In that case I'm not 100% sure that 'selectionRange' is better than 'range' for our purposes:
/**
* The range enclosing this symbol not including leading/trailing whitespace
* but everything else like comments. This information is typically used to
* determine if the clients cursor is inside the symbol to reveal in the
* symbol in the UI.
*/
range: Range;
/**
* The range that should be selected and revealed when this symbol is being
* picked, e.g. the name of a function. Must be contained by the `range`.
*/
selectionRange: Range;
perhaps we should pass a 'range_property="range"' argument to this function instead?
There was a problem hiding this comment.
Reviewed 7 of 7 files at r5, all commit messages.
Reviewable status: 0 of 2 LGTMs obtained (and 1 stale) (waiting on @bstaletic)
There was a problem hiding this comment.
Reviewable status: 0 of 2 LGTMs obtained (and 1 stale) (waiting on @puremourning)
ycmd/completers/language_server/language_server_completer.py line 3413 at r5 (raw file):
Previously, puremourning (Ben Jackson) wrote…
I think this might be surprising when used in other contexts. There are other request that have 'selectionRange' , such as "DocumentSymbol" In that case I'm not 100% sure that 'selectionRange' is better than 'range' for our purposes:
/** * The range enclosing this symbol not including leading/trailing whitespace * but everything else like comments. This information is typically used to * determine if the clients cursor is inside the symbol to reveal in the * symbol in the UI. */ range: Range; /** * The range that should be selected and revealed when this symbol is being * picked, e.g. the name of a function. Must be contained by the `range`. */ selectionRange: Range;perhaps we should pass a 'range_property="range"' argument to this function instead?
I was considering that too. I was not sure about DocumentSymbol either.
Implemented your suggestion. That should also generalize to originSelectionRange and targetSelectionRange, were we ever to need a LocationLink LSP type.
6f49fc9 to
cc2e135
Compare
fae3dc7 to
253f35c
Compare
```go
package main
func f() (int) {
return 5;
}
func g() (int) {
return f() + f();
}
func h() (int) {
var x = g();
return f() + x;
}
```
With incoming calls request on `g()`, the response should be something
like this
```python
{
'locations': [ location_of_call_to_g_inside_h ],
'root_location': location_of_h_function_name
}
```
This allows clients to:
1. Jump to the actual call site, using `locations` list.
2. Switch to outgoing calls, by preparing a new hierarchy, using
`root_location` object.
…ion-like objects This fixes all of the remaining bugs when requesting outgoing calls of an incoming call hierarchy item. Specifically, we *want* `selectionRange` for the hierarchy root and for `root_location` of incoming call hierarchy items. JDT is special and needs `range` in the second case.
There was a problem hiding this comment.
Reviewed 15 of 15 files at r6, all commit messages.
Reviewable status: 1 of 2 LGTMs obtained (waiting on @bstaletic)
ycmd/completers/typescript/typescript_completer.py line 823 at r6 (raw file):
def _Hierarchy( self, request_data, args ): self._Reload( request_data )
is this reload needed? I suspect that we can rely on the reload from the prepare step?
ycmd/tests/typescript/subcommands_test.py line 1203 at r6 (raw file):
@SharedYcmd def test_Subcommands_OutgoingCallHierarchy( self, app ):
I take it there is no type hierarchy for typescript?
These are mandatory, but were forgotten in the previous docs update.
There was a problem hiding this comment.
Dismissed @puremourning from a discussion.
Reviewable status: 0 of 2 LGTMs obtained (and 1 stale) (waiting on @puremourning)
ycmd/completers/typescript/typescript_completer.py line 823 at r6 (raw file):
Previously, puremourning (Ben Jackson) wrote…
is this reload needed? I suspect that we can rely on the reload from the prepare step?
Good point.
I started thinking about a potential scenario where a client would keep the hierarchy tree around and then after editing stuff go back to it, but
- Then
_Reload()would be called for a different reason anyway. - If the call site changes the hierarchy will be wrong.
Dropped the reload.
ycmd/tests/typescript/subcommands_test.py line 1203 at r6 (raw file):
Previously, puremourning (Ben Jackson) wrote…
I take it there is no type hierarchy for typescript?
That's right.
|
Thanks for sending a PR! |
This is the implementation of the server side changes needed to have useful support for LSP call/type hierarchies.
While the clien side changes deserve more attention, the server side should be fine to review and merge.
What's definitely missing are tests and API documentation.
On top of that, what do we want to do with the old
GoToCollers/GoToCallees? I see three options:This change is