Add container information to CallHierarchyItem

[mjbvz]

From microsoft/vscode#89616

Search Terms

• call hierarchy
• tsserver

Problem

Currently using the call hierarchy api, it can be difficult to browse through long list of callers and understand where those callers are:

Suggestion

Add optional information about the container on the CallHierarchyItem type. For example, the NavTooItem has:

containerName?: string;
containerKind?: ScriptElementKind;

We should consider something similar for CallHierarchyItem

/cc @jrieken

[DanielRosenwasser]

Given that you're in call hierarchy, won't you end up with many of the same icons anyway? What sorts of distinctions would be helpful here, and would they only apply to methods on classes?

[mjbvz]

Yes I don't think we would use the containerKind to display an icon. It may be helpful to understand the type of the callee for example

[mjbvz]

@jrieken Do you think we should show the file name for every entry?

This is similar to workspace symbol search results

[jrieken]

In a very first version we showed the file name and that was disliked - often different (contained) types are in the same file. Also file paths are very long.

That's why container name is wanted, which sometimes might be a file name but often is a class or namespace name. Having this will provide much more context and will make it easier to work with the call hierarchy (which by its nature can be confusing already)

[mjbvz]

Here's my proposal for the TS Server api:

interface CallHierarchyItem {
    /**
      * Name of symbol's container symbol (if any), such as the class name.
     */
    containerName?: string;
}

Not sure we have a use for containerKind so I'm leaving that out for now

[jrieken]

@mjbvz did we adopt this? I don't see a difference when selfhosting

[mjbvz]

@andrewbranch Looks like TS does not return a value for containerName. It's undefined in all the cases I've tested

[andrewbranch]

It turns out there’s a data conversion function on the server layer, which our normal test suite doesn’t touch, that returns an object with a specific set of keys, so the new property was left out of the serialization. PR incoming.