-
Notifications
You must be signed in to change notification settings - Fork 29.8k
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
call hierarchy api #80112
call hierarchy api #80112
Conversation
/cc @rbuckton Since I know you were were looking into microsoft/TypeScript#31863 |
Another round of API ideas (closer to the original) class CallHierarchyItem {
kind: SymbolKind;
name: string;
detail?: string;
uri: Uri;
range: Range;
selectionRange: Range;
}
interface CallsTo {
source: CallHierarchyItem,
sourceRanges: Range[]
}
interface CallsFrom {
sourceRanges: Range[],
target: CallHierarchyItem
}
interface CallHierarchyItemProvider {
resolveCallHierarchyItem(document: TextDocument, postion: Position, token: CancellationToken): ProviderResult<CallHierarchyItem>;
provideCallsTo(target: CallHierarchyItem, token: CancellationToken): ProviderResult<CallsTo[]>;
provideCallsFrom(source: CallHierarchyItem, token: CancellationToken): ProviderResult<CallsFrom[]>;
} |
Will call hierarchy only be limited to calls to/from, or is it possible it will evolve to support other concepts? For example:
|
Anything callable and anything that makes calls. The obvious are functions/methods but constructors and getters/setters are also valid. Generally, VS Code doesn't care/know about what's valid and it will simply ask the language brains for incoming/outgoing calls for a document position. |
fyi - closing this in favour of #70231 (comment). That explains the latest proposal which we are very likely to settle on. Let's continue the discussions there. |
This PR refines the call hierarchy API proposal and adopts the UX for it. The new proposal is