Use the selection range when resolving call hierarchy items #5110
Conversation
|
The fun thing about call hierarchy is that it exercises the goto definition and find references machinery. |
matklad
left a comment
matklad
left a comment
There was a problem hiding this comment.
r=me with slow test removed
| } | ||
|
|
||
| #[test] | ||
| fn test_issue_5103() { |
There was a problem hiding this comment.
We don't add regression slow tests, as they are slow. So, this either has to be untested, or we need to move the checks to the type level.
|
|
||
| let doc = TextDocumentIdentifier::new(item.uri); | ||
| let frange = from_proto::file_range(&snap, doc, item.range)?; | ||
| let frange = from_proto::file_range(&snap, doc, item.selection_range)?; |
There was a problem hiding this comment.
I wonder if that means that our API and/or protocol are off. Positions only make sense for the first request which initializes call hierarchy. Navingating to incoming/outgoing call should not use positions. At the same time, round-tripping some kind of persistent cookies seems awkward.
I guess, for the time being this is a fine fix, but this needs more design long-term.
There was a problem hiding this comment.
I was thinking of reconstructing the call item and passing that down and may try something like that in a followup PR.
Add a test in call_hierarchy that already passed Fixes rust-lang#5103
kjeremy
force-pushed
the
call-hierarchy-selection-range
branch
from
fa0877a to
20d8648
Compare
|
bors r+ |
2 participants
Add a test in call_hierarchy that already passed and a corresponding
heavy test to test the LSP requests which exposed the issue.
Fixes #5103