You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Let's say function foo() is calling bar() and only once. With jdt.ls, selectionRange spans the call site. With other servers, selectionRange spans the name of foo().
This is important to me, because I want the ability to take the data from the incomingCallHierarchy and send a new prepareCallHierarchy request from the calling function (foo()).
I can also think of two other reasons why the current JDT behaviour is bad:
It seems useless to have selectionRange == fromRanges[0], as it does not provide any additional information about the hierarchy item.
The documentation for from seems to imply that the data should be about the calling function, not the called function.
Granted, I can achieve my goal with some JDT specific hacks, as JDT can do what I want if I switch to using range instead of selectionRange. However, that seems counterintuitive and would require server specific hacks for some other servers.
The text was updated successfully, but these errors were encountered:
I am experiencing the same issue. Typescript and pyright seem to provide the selectionRange of the caller, not the callsite, in this field.
The specification also suggests this, which seems to imply everything in from should refer to the caller, and callsite stuff should go in fromRanges:
exportinterfaceCallHierarchyIncomingCall{/** * The item that makes the call. */from: CallHierarchyItem;/** * The ranges at which the calls appear. This is relative to the caller * denoted by `this.from`. */fromRanges: Range[];}
I am implementing call hierarchies in ycmd and ended up facing a situation where jdt.ls behaves differently than the other servers I have tested.
The response to the
incomingCallHierarchy
request looks something like this (irrelevant properties intentionally omitted):Let's say function
foo()
is callingbar()
and only once. With jdt.ls,selectionRange
spans the call site. With other servers,selectionRange
spans the name offoo()
.This is important to me, because I want the ability to take the data from the
incomingCallHierarchy
and send a newprepareCallHierarchy
request from the calling function (foo()
).I can also think of two other reasons why the current JDT behaviour is bad:
selectionRange == fromRanges[0]
, as it does not provide any additional information about the hierarchy item.from
seems to imply that the data should be about the calling function, not the called function.Granted, I can achieve my goal with some JDT specific hacks, as JDT can do what I want if I switch to using
range
instead ofselectionRange
. However, that seems counterintuitive and would require server specific hacks for some other servers.The text was updated successfully, but these errors were encountered: