Call Hierarchy

[svenefftinge]

The LSP should define a request from the client to server to obtain callers for a definition as well as obtaining the containing callable definitions (e.g. containing method declaration).
Based on that an editor can provide a call hierarchy helping the user to understand the code better.

[MarkZ3]

Cquery has an extension for this. Perhaps a god place to start:
https://github.com/cquery-project/cquery/blob/master/src/messages/cquery_call_hierarchy.cc#L23

[dbaeumer]

See also the discussion here microsoft/vscode-languageserver-node#346 about and idea to how more general implement this.

[kjeremy]

This is now implemented in rust analyzer: rust-lang/rust-analyzer#2698

[HighCommander4]

I am implementing this new API in the C++ language server clangd, and I have run into an issue:

The API consists of an initial textDocument/prepareCallHierarchy request to get a CallHierarchyItem based on a file location, and then callHierarchy/incomingCalls and callHierarchy/outgoingCalls requests which send a CallHierarchyItem as input and get back a list of CallHierarchyItems representing the children of the input item in the tree.

If the language server uses some sort of internal identifier to identify entities (such as functions) in the workspace, there is no way with the current API to "stash" such an identifier in a CallHierarchyItem such that the client sends it back in an incomingCalls or outgoingCalls request and the server knows what to operate on using that identifier. Instead, the server needs to "re-identify" the entity in question based on the user-facing fields in the CallHierarchyItem (name, location, etc.) only. For some server implementations, including ours, this process can be expensive and inaccurate.

There is a type hierarchy proposal which has a lot in common with this call hierarchy proposal, including having TypeHierarchyItems and calls to resolve the hierarchy one level at a time. In that proposal, TypeHierarchyItem has an optional data field of type any which can be used (and is used, by the clangd implementation of the type hierarchy proposal) to stash the server's internal identifier.

Could such a data field please be added to CallHierarchyItem as well?

[dbaeumer]

Added the data property.

Also closing the issue since call hierarchies are part of the upcoming 3.16.0 spec.