Call hierarchy support

[smhc]

Is there any chance of implementing a call hierarchy similar to lsp-mode for emacs? It uses the ccls call hierarchy command (plus a tree component of some kind) to generate a dependency tree like this:

Rather than rely on the non-standard hierarchy command, it would be great if vim-lsp could use the 'References' functionality to obtain references, then recursively obtain parent references as a user expands them within a tree. It would require a tree view of some kind, similar to nerdtree etc.

This may be outside the realm of vim-lsp - but it is a quite desirable feature that none of the LSP clients for vim currently implement (that I'm aware of).

[m-pilia]

I apologise in advance for the shameless plug, but vim-ccls may be the kind of plugin you are looking for. It works on top of vim-lsp too!

[smhc]

That looks pretty much like what I am taking about.

I personally prefer clangd over ccls, I had a few issues with indexing with ccls. It may have changed since then.

I notice that call hierarchy support is now part of the LSP spec, though not yet implemented by clangd.

However I guess it should be possible to generate a reverse (the most useful) "reference" hierarchy tree incrementally by calling "get references" repeatedly.

[m-pilia]

I think textDocument/references only returns a list of locations, so it should not be possible to recover the caller functions without parsing the code around the calls. I am looking forward to see the textDocument/callHierarchy supported by some servers, and I hope similar methods will be introduced for inheritance and members.

To implement a call hierarchy viewer here in vim-lsp, it would be possible to directly re-use the tree viewer I made. Not that it is hard to re-implement, but it can save some work. I made it as a general purpose library, independent and completely decoupled from the ccls-related part of the plugin. Here is the source, its documentation, and it comes with unit tests. And it is under MIT license, so it could be bundled in this project without any problem.

[smhc]

Yes you're quite right re: references and callers.

I have seen your tree implementation and agree vim-lsp should adopt it or something similar to show the call hierarchy. A shame clangd doesn't implement it yet, but I'm sure it's coming.

[prabirshrestha]

@m-pilia Your general purpose tree seems awesome. I have been wanting to have a lightweight generic tree provider in vim for ages. I shared some thoughts here lambdalisue/vim-fern#3.

Seems like we use different test framework and that could cause maintenance headache in the future.

@m-pilia If you don't mind are you inteserted in sending PR for call hierarchy support in vim-lsp?

[m-pilia]

@prabirshrestha Yes, I can work on a PR for this feature. So far I have not tested the official textDocument/callHierarchy method, but I hope it works without too many quirks...

I second your idea of having a generic tree viewer plugin. I was actually considering to move the tree viewer out from vim-ccls to a separate plugin. The code is already decoupled, it is just a matter of moving the relevant files to a new repo. I was wondering if having an external dependency in vim-lsp for this would be ok for you.

[smhc]

@yegappan once wrote a generic tree control for vim, but it was hosted on geocities and has since been lost. I've never seen the code and I don't know whatever happened to it:

https://marc.info/?l=vim&m=116083925310181&w=2

[prabirshrestha]

@m-pilia +1 for create a new repo that is just for treeview. That way we don't need to duplicate tests or worry about it. I actually think I did a mistake making allowing others depend on async.vim directly. This means I can never change the apis that would cause breaking changes even if it meant it was better. You may face the same problem with treeview plugin. I have always wanted to have a util method similar to :Vitalize in vital.vim which easily allows people to embed it easily. :Vitalize --name=your_plugin_name $HOME/.vim/bundle/your_plugin_dir/ but simplify it. :EmbedTreeViewPlugin --name=lsp -plugin-folder=~/.vim/bundle/vim-lsp --embed-folder=utils/treeview so it will be generated in ~/.vim/bundle/vim-lsp/utils/treeview/ folder. Then plugin authors can use lsp#utils#treeview#...().

Also would be good if one can just create a provider so we don't have to manually call render methods.
fila.vim seems to have a PR on this. lambdalisue/vim-fern#10. TreeDataProvider api can be found at https://code.visualstudio.com/api/references/vscode-api#TreeDataProvider.

[prabirshrestha]

@m-pilia I have filed an issue on your side to extract the tree so we can embed it in vim-lsp. m-pilia/vim-ccls#15

[m-pilia]

@prabirshrestha Thanks! I want to move this forward asap. Recently I have put quite some thoughts on this task and how to do it, but I have been silent for a while due to a crowded backlog.

[m-pilia]

I made a new repo containig the library as it is now, and I am making ready to refactor it. The main issues are about the data API and the reliance on ftplugin.

I think it should not be too much work for me to fix them, but I am a bit slow due to personal backlog. Luckily it should not be too urgent, since I am not aware of any major language server currently providing an implementation of the textDocument/callHierarchy method (at least, I looked around recently and I could find none).

[prabirshrestha]

It will be good if we can easily copy paste the code and embed in in vim-lsp. One mistake I did with async.vim was make it like a lib which means I can never change the apis without breaking even if it is better.

[m-pilia]

I will strive to make it possible to embed it. It would be nice if it were possible to have it as a git submodule/subtree, but I do not think there is any straightforward way to do it with git.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[hasufell]

https://microsoft.github.io/language-server-protocol/specifications/specification-current/#textDocument_prepareCallHierarchy

[jlevon]

this has had clangd support for a while, is there any chance on this being reopened and worked on again?
Alternatively does anybody know another implementation? Even a cmdline cli?
(I tried to check out ccls briefly but predictably it won't compile due to C++ being C++)