Extra detail for callHierarchy

[nagi1999a]

Recently I started to use clangd to help developing, and find it extremely great!
However, in VScode, I found that when showing call hierarchy, there is no extra information about each function that showed at the right of function name, which utilized the detail field in the responded LSP json.

Most extensions in vscode utilized the field to show the file name and/or the line number information, and we can also make it possible to show file name by simply add one line to the clang-tools-extra/clangd/XRefs.cpp

diff --git a/clang-tools-extra/clangd/XRefs.cpp b/clang-tools-extra/clangd/XRefs.cpp
index cd9092664..a6f0dcbcd 100644
--- a/clang-tools-extra/clangd/XRefs.cpp
+++ b/clang-tools-extra/clangd/XRefs.cpp
@@ -1757,6 +1757,7 @@ static std::optional<HierarchyItem> symbolToHierarchyItem(const Symbol &S,
   // (https://github.com/clangd/clangd/issues/59).
   HI.range = HI.selectionRange;
   HI.uri = Loc->uri;
+  HI.detail = llvm::sys::path::filename(Loc->uri.file()).str();
 
   return HI;
 }

And then we can see the changes in the VScode:

It might be great that we can customize the information by some arguments of clangd. Also, current implementation seems to not split each call within a single function, maybe we can also have arguments to control the behavior, too.

Thanks again for the great tool!

[HighCommander4]

we can also make it possible to show function name by simply add one line to the clang-tools-extra/clangd/XRefs.cpp

I think you meant to say "to show the file name", right?

Showing the file name sounds useful to me. I do have one concern about it: in #915, it was proposed that the "detail" field should be used for the function signature, which also seems to be useful. However, we only have one "detail" field.

Do you think we should somehow combine multiple pieces of information (e.g. file name and function signature) into the detail field? Or just pick one of them?

[nagi1999a]

I think you meant to say "to show the file name", right?

Yes, thanks for quick reply and sorry for the mistake!

Do you think we should somehow combine multiple pieces of information (e.g. file name and function signature) into the detail field? Or just pick one of them?

I think we can choose one of them as the default behavior, and switch using yaml configuration, like filename | signature | all, because it seems that either case are useful in different places.
In addition, for the all option, we may provide json type results, to make other extensions easily parse them.

[HighCommander4]

I think we can choose one of them as the default behavior, and switch using yaml configuration, like filename | signature | all, because it seems that either case are useful in different places.

A couple of additional things I realized:

• For methods, it's also important to show the class name.
• There is a patch under review adding support for outgoing calls, which actually populates the detail field with the function's fully qualified name.
  • This includes the class name for methods, and any namespaces the function or class is contained in. It does also repeat the function name itself, which is a bit redundant; maybe that could be removed.

And I've looked at what some other language servers do:

• typescript: shows class name (does not repeat function name), does not show signature
• rust-analyzer: shows signature (the full declaration including the function name), does not show class name

I'm not opposed to having a config option governing this personally, though I'd want to get some feedback from other maintainers on that (some have expressed a preference for being judicious with the use of config options). Either way it's important to have a good default.

In addition, for the all option, we may provide json type results, to make other extensions easily parse them.

Could you clarify what you mean by extensions here -- do you mean editor extensions which are language clients, like vscode-clangd?

[nagi1999a]

Thanks for the detail survey on this topic!

It seems that different language server have distinct implementations! It is also interesting that, in vscode, official extensions for python and javascript do not show extra information in call hierarchy. And the official extension for c/cpp, vscode-cpptools, and some 3rd party ones, c-hierarchy & VSCode-C-Call-Hierarchy, tends to show the filename and line number.

Could you clarify what you mean by extensions here -- do you mean editor extensions which are language clients, like vscode-clangd?

Yes, extensions may caught LSP json and do some post-processing before actually send to the editor, they might provide advanced mixed format for different purposes, like "@" or "\n", but will require extra effort for each extension to modify to intercept and forward LSP messages.

[HighCommander4]

Another idea to consider could be to use a textual separator like "•" to combine multiple things into detail.

For example: classname • signature • filename

The "classname" part would only need to be included for C++ methods.

The "signature" we might also limit to C++, since in C functions cannot be overloaded. (And maybe even in C++ we could show the signature only for functions which are actually overloaded, though that might require extra index lookups to determine.)

That would leave just the filename in C, which is what you originally asked for.