Add support for LSP-standard TypeHierarchy

[mickaelistria]

But keep legacy command which is still used by vscode-java.

Also-by: Mickael Istria [email protected]

[mickaelistria]

/cc @CsCherrYY this is an adaptation of your patch in #2033 , retaining existing typehierarchy commands so those can still be used by vscode-java. This patch would allow other clients to benefit from LSP-standard type hierarchy without breaking vscode-java.

[rgrunber]

Looks fine to me.

I did notice that we don't check if the client supporst the type hierarchy client capability from initialize, but we also don't seem to do it for the call hierarchy provider, so I guess we can leave it like this for now.

Given that Eclipse IDE intends to support, and vscode-languageclient already does (but I think we are overriding it with our delegate use) it should be fine for now.

[mickaelistria]

Thank you!

[mickaelistria]

Unfortunately, build https://ci.eclipse.org/ls/job/jdt-ls-master/1789/ has failed. Is this related?

[testforstephen]

Looks fine to me.

I did notice that we don't check if the client supporst the type hierarchy client capability from initialize, but we also don't seem to do it for the call hierarchy provider, so I guess we can leave it like this for now.

Given that Eclipse IDE intends to support, and vscode-languageclient already does (but I think we are overriding it with our delegate use) it should be fine for now.

In VS Code, we see two "show type hierarchy" menus with this PR merged. Apparently we need a client flag to control whether to register type hierarchy in init handler.

[rgrunber]

Right. Then we definitely need it for clients to behave correctly.

[mickaelistria]

I just tried and confirm it's working well in Eclipse IDE!

Apparently we need a client flag to control whether to register type hierarchy in init handler.

I hope flag to disable standard operations will be opt-out (so clients that do support standard LSP won't have to enable anything particular, others will have to set the flag to disable LSP's standard typeHierarchy).

But at this stage, wouldn't it be simpler on mid-term for VSCode-Java to also adopt the LSP official TypeHierarchy? What's missing in it to retain the legacy command?

[testforstephen]

The standard LSP only supports supertype and subtypes, but no class hierarchy view. The current vscode-java supports 3 different views, and keep it to avoid feature loss.

[rgrunber]

#2814 should fix the issue.

[rgrunber]

@mickaelistria the previous approach was signalling the server provides type hierarchy without first checking whether the client supports dynamic registration. Now the spec is followed correctly with the recent PR.

You can try it out to see if it still works. I think it should because I don't see setTypeHierarchy(..) anywhere in https://github.com/eclipse/lsp4e/blob/a60390688b37ae879bd773679ef73d7e542b77f9/org.eclipse.lsp4e/src/org/eclipse/lsp4e/internal/SupportedFeatures.java#L67-L122 , so the language server should register the static capability for the Eclipse IDE, which is what was probably happening before.