-
Notifications
You must be signed in to change notification settings - Fork 399
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Incoming call's hierarchy item's selectionRange behaves differently to all other (tested) servers #3184
Comments
For reference, here's a related discussion between myself and a rust-analyzer maintainer: |
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 export interface CallHierarchyIncomingCall {
/**
* 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[];
} |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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: