Type hierarchy view improvements

[stephan-razin]

• Fix collapsible state for classes without children.
• Fix base-classes hierarchy displaying for classes without children.
• Improve icons and details information like native vscode Peek Type Hierarchy.

[HighCommander4]

The code in src/type-hierarchy.ts is implementing a pre-standard version of the type hierarchy protocol, which has since been replaced by the standard version (whose UI implementation lives in vscode itself). According to this check, this old implementation is only active if the clangd server does not advertise the standardTypeHierarchyProvider capability, which it has been doing since clangd 16.

Are you using an older version of clangd than clangd 16? Or are you somehow seeing this code being used with newer clangd versions?

[stephan-razin]

clangd --version
clangd version 20.1.8 (https://github.com/llvm/llvm-project 87f0227cb60147a26a1eeb4fb06e3b505e9c7261)
Features: windows+grpc
Platform: x86_64-pc-windows-msvc

Standard type hierarchy works, and clangd.typeHierarchyView works also. It's registerd here. So, view is available independing of server version.

If this view is deprecated, this PR has no sense. But, IMHO, clangd.typeHierarchyView looks more useful:
Exaple:

class A {};
class B1 : public A {};
class B2 : public A {};
class C : public B1 {};
class D1 : public C {};
class D2 : public C {};
class E : public D2 {};

Standard type hierarchy for C:

clangd.typeHierarchyView for C

PS: command to show view:

[HighCommander4]

Standard type hierarchy works, and clangd.typeHierarchyView works also. It's registerd here. So, view is available independing of server version.

Good find. I think this is unintentional / an oversight though: the context menu item to invoke call hierarchy is made conditional on the server only supporting the non-standard extension here, and the command should have been made conditional too, but it seems this was overlooked.

IMHO, clangd.typeHierarchyView looks more useful

Are you referring to the fact that our type hierarchy view shows both subtypes (derived classes) and supertypes (base classes) in the same tree?

The standard one can also show supertypes, just not in the same tree (there is a "Show supertypes" button at the top of the type hierarch view).

[stephan-razin]

Are you referring to the fact that our type hierarchy view shows both subtypes (derived classes) and supertypes (base classes) in the same tree?

Yes, I know about "show supertypes" button, and it's looks like a matter of taste, which one is better.

And also one point: clangd hierarchy does not show expand button for types without subtypes, but standard one shows it always.

So, if clangd type hierarchy is deprecated and used for old versions compatibiliy only, I guess you can reject this PR.

[HighCommander4]

clangd hierarchy does not show expand button for types without subtypes, but standard one shows it always.

I do agree that's nicer.

VSCode's standard type hierarchy view could be changed to have this behaviour too. You could consider filing an issue about that in the https://github.com/microsoft/vscode/ repo, and if fixed then users of the type hierarchy view in all applicable languages would benefit.

So, if clangd type hierarchy is deprecated and used for old versions compatibiliy only, I guess you can reject this PR.

Yeah, I think that, since the only reason we had our own type hierarchy view to begin with was that there wasn't a standard one at the time, we should be moving in the direction of deprecating/removing ours rather than enhancing it.

cc @hokein and @kadircet in case you have a different opinion

[hokein]

Yeah, I think that, since the only reason we had our own type hierarchy view to begin with was that there wasn't a standard one at the time, we should be moving in the direction of deprecating/removing ours rather than enhancing it.

+1, the existing clangd-vscode view should be considered deprecated in favor of the standard one. While I personally find our view which shows both base and derived classes more useful, the extra maintenance burden of a separate hierarchy view is not warranted.