Proposal of the type hierarchy protocol extension. #426

kittaakos · 2018-10-15T11:43:51Z

Note:
Another related PR in this repository: #346
The original GH issue for the PR: microsoft/language-server-protocol#136

Type hierarchy in action with Eclipse Theia and the JDT language server.

Signed-off-by: Akos Kitta [email protected]

CC: @svenefftinge

kittaakos · 2019-01-23T12:38:29Z

I have updated the proposal based on #346 (comment).

dbaeumer · 2019-01-25T08:51:38Z

protocol/src/protocol.typeHierarchy.proposed.md

+      /**
+       * `true` if the language client supports super- and subtype hierarchies. Defaults to `false`.
+       */
+      typeHierarchy?: boolean;


Actually the pattern here is to not provide textDocument.typeHierarchy property if the client doesn't support it. The capability should flag if dynamic registration is supported.

dbaeumer · 2019-01-25T08:56:34Z

protocol/src/protocol.typeHierarchy.proposed.md

+   * Server capability for calculating super- and subtype hierarchies.
+   * The language server supports the type hierarchy language feature, if this capability is set to `true`.
+   */
+  typeHierarchy?: boolean;


Since this is a new request we should support to register that for a specific document selector as well. See https://github.com/Microsoft/vscode-languageserver-node/blob/master/protocol/lib/protocol.implementation.d.ts#L26 how this is supported in the LSP. Servers are only allowed to use this registration option if the client signals dynamic registration.

dbaeumer · 2019-01-25T09:00:07Z

protocol/src/protocol.typeHierarchy.proposed.md

+   * The direction of the hierarchy levels to resolve. Valid values are: `parents`, `children`, or `both`.
+   * Defaults to `children`.
+   */
+  direction?: 'parents' | 'children' | 'both';


I think we need to clarify what should happen if a hierarchy item has already the parents resolved and is asked to resolve its children. Should the client send the parents again or is it allowed to leave them out. I would opt for the second.

I do like strings literals over numbers but so far we used numbers for all enum like types. To keep things consistent I would like to opt to say with this unless we have a strong reason to do otherwise.

I know I proposed this earlier but now I am more for consistency :-)

I would opt for the second.

+1

@dbaeumer, I would have a follow-up question on this: what should happen in general, if something is already resolved and the client requests to resolve it again?

In the JDT reference implementation, I did for this language feature, I blindly resolve everything from scratch, because:

the text document that is referenced by the TypeHierarchyItem might have changed meanwhile, so the item I am trying to resolve is not at the same cursor position anymore,

the type hierarchy of my TypeHierarchyItem might have changed.

Thank you!

dbaeumer · 2019-01-25T10:02:40Z

protocol/src/protocol.typeHierarchy.proposed.md

+   * The direction of the hierarchy levels to resolve. Valid values are: `parents`, `children`, or `both`.
+   * Defaults to `children`.
+   */
+  direction?: 'parents' | 'children' | 'both';


I know I proposed this earlier but now I am more for consistency :-)

kittaakos · 2019-01-25T13:26:19Z

I have updated this PR based on the review feedback.

Based on microsoft/vscode-languageserver-node#426 (review) Signed-off-by: Akos Kitta <[email protected]>

Signed-off-by: Akos Kitta <[email protected]>

Based on microsoft/vscode-languageserver-node#426 (review) Signed-off-by: Akos Kitta <[email protected]>

HighCommander4 · 2019-02-01T06:11:47Z

protocol/src/protocol.typeHierarchy.proposed.md

+  /**
+   * The direction of the hierarchy levels to resolve.
+   */
+  direction?: TypeHierarchyDirection


Does this have a default? What should happen if the client provides a value for resolve but not for direction?

See: microsoft/vscode-languageserver-node#426 Signed-off-by: Alex Tugarev <[email protected]>

sam-mccall · 2019-02-11T08:52:44Z

protocol/src/protocol.typeHierarchy.proposed.md

+
+_Requests_:
+
+The `Type Hierarchy Request` is sent from the client to the server to retrieve a `TypeHierarchyItem` at a given cursor position. If computing full type hierarchy items is expensive, servers can additionally provide a handler for the type hierarchy item resolve request (`typeHierarchy/resolve`). This request would also allow to specify if the item should be resolved and whether sub- or supertypes are to be resolved. If no item can be retrieved for a given text document position, returns with `null`.


This seems pretty complicated - is there evidence that a) lazy resolving is needed and b) eager resolving is also needed?

sam-mccall · 2019-02-11T09:00:15Z

protocol/src/protocol.typeHierarchy.proposed.md

+  /**
+   * The hierarchy levels to resolve. `0` indicates no level. When not defined, it is treated as `0`.
+   */
+  resolve?: number;


can we specify that the server may resolve more than this number of levels, e.g. if it's cheap to do so?

Client doesn't know whether it's cheap or expensive, so may specify low resolve (e.g. 1). However for some servers (in particular for clangd), resolving parent links one-at-a-time in a loop is much more expensive than doing it all at once - the cost is in finding the first parent, the rest are free.

See: microsoft/vscode-languageserver-node#426 Signed-off-by: Alex Tugarev <[email protected]>

@nridge

Summary: Patch by Nathan Ridge(@nridge)! This is an LSP extension proposed here: microsoft/vscode-languageserver-node#426 An example client implementation can be found here: eclipse-theia/theia#3802 Reviewers: kadircet, sammccall Reviewed By: kadircet Subscribers: jdoerfert, sammccall, cfe-commits, mgorny, dschaefer, simark, ilya-biryukov, ioeric, MaskRay, jkorous, arphaman, kadircet Tags: #clang Differential Revision: https://reviews.llvm.org/D56370 llvm-svn: 356445

@nridge

Summary: Patch by Nathan Ridge(@nridge)! This is an LSP extension proposed here: microsoft/vscode-languageserver-node#426 An example client implementation can be found here: eclipse-theia/theia#3802 Reviewers: kadircet, sammccall Reviewed By: kadircet Subscribers: jdoerfert, sammccall, cfe-commits, mgorny, dschaefer, simark, ilya-biryukov, ioeric, MaskRay, jkorous, arphaman, kadircet Tags: #clang Differential Revision: https://reviews.llvm.org/D56370 git-svn-id: https://llvm.org/svn/llvm-project/clang-tools-extra/trunk@356445 91177308-0d34-0410-b5e6-96231b3b80d8

@nridge

Summary: Patch by Nathan Ridge(@nridge)! This is an LSP extension proposed here: microsoft/vscode-languageserver-node#426 An example client implementation can be found here: eclipse-theia/theia#3802 Reviewers: kadircet, sammccall Reviewed By: kadircet Subscribers: jdoerfert, sammccall, cfe-commits, mgorny, dschaefer, simark, ilya-biryukov, ioeric, MaskRay, jkorous, arphaman, kadircet Tags: #clang Differential Revision: https://reviews.llvm.org/D56370 llvm-svn: 356445

HighCommander4 · 2019-07-28T00:55:03Z

Note that there is now a server implementation of this in clangd (C++ language server), using the protocol proposed here.

9.0.0: Improvements to clangd * Background indexing is on by default When using clangd, it will build an index of your code base (all files listed in your compile database). This index enables go-to-definition, find-references, and even code completion to find symbols across your project. This feature can consume a lot of CPU. It can be disabled using the --background-index=false flag, and respects -j to use fewer threads. The index is written to .clangd/index in the project root. * Contextual code actions Extract variable, expand auto, expand macro, convert string to raw string. More to come in the future! * Clang-tidy warnings are available These will be produced for projects that have a .clang-tidy file in their source tree, as described in the clang-tidy documentation. * Improved diagnostics Errors from headers are now shown (on the #including line). The message now indicates if fixes are available. Navigation between errors and associated notes is improved (for editors that support Diagnostic.relatedInformation). * Suggested includes When a class or other name is not found, clangd may suggest to fix this by adding the corresponding #include directive. * Semantic highlighting clangd can push syntax information to the editor, allowing it to highlight e.g. member variables differently from locals. (requires editor support) This implements the proposed protocol from microsoft/vscode-languageserver-node#367 * Type hierachy Navigation to base/derived types is possible in editors that support the proposed protocol from microsoft/vscode-languageserver-node#426 * Improvements to include insertion Only headers with #include-guards will be inserted, and the feature can be disabled with the --header-insertion=never flag. Standard library headers should now be inserted more accurately, particularly for C++ other than libstdc++, and for the C standard library. * Code completion Overloads are bundled into a single completion item by default. (for editors that support signature-help). Redundant const/non-const overloads are no longer shown. Before clangd is warmed up (during preamble build), limited identifier- and index-based code completion is available. * Format-on-type A new implementation of format-on-type is triggered by hitting enter: it attempts to reformat the previous line and reindent the new line. (Requires editor support). * Toolchain header detection Projects that use an embedded gcc toolchain may only work when used with the corresponding standard library. clangd can now query the toolchain to find these headers. The compilation database must correctly specify this toolchain, and the --query-driver=/path/to/toolchain/bin/* flag must be passed to clangd. * Miscellaneous improvements Hover now produces richer Markdown-formatted text (for supported editors). Rename is safer and more helpful, though is still within one file only. Files without extensions (e.g. C++ standard library) are handled better. clangd can understand offsets in UTF-8 or UTF-32 through command-line flags or protocol extensions. (Useful with editors/platforms that don’t speak UTF-16). Editors that support edits near the cursor in code-completion can set the textDocument.completion.editsNearCursor capability to true, and clangd will provide completions that correct . to ->, and vice-versa. Improvements to clang-tidy New OpenMP module. New abseil-duration-addition check. New abseil-duration-conversion-cast check. New abseil-duration-unnecessary-conversion check. New abseil-time-comparison check. New abseil-time-subtraction check. New android-cloexec-pipe check. New android-cloexec-pipe2 check. New bugprone-branch-clone check. New bugprone-posix-return check. New bugprone-unhandled-self-assignment check. New fuchsia-default-arguments-calls check. New fuchsia-default-arguments-declarations check. New google-objc-avoid-nsobject-new check. New google-readability-avoid-underscore-in-googletest-name check. New llvm-prefer-isa-or-dyn-cast-in-conditionals check. New modernize-use-trailing-return-type check. New objc-super-self check. New openmp-exception-escape check. New openmp-use-default-none check. New readability-convert-member-functions-to-static check. New alias cert-oop54-cpp to bugprone-unhandled-self-assignment was added. New alias cppcoreguidelines-explicit-virtual-functions to modernize-use-override was added. Added UseAssignment option to cppcoreguidelines-pro-type-member-init The fuchsia-default-arguments check has been removed. The google-runtime-int check has been disabled in Objective-C++. The modernize-use-override now supports OverrideSpelling and FinalSpelling options. The misc-throw-by-value-catch-by-reference now supports WarnOnLargeObject and MaxSize options to warn on any large trivial object caught by value. The Acronyms and IncludeDefaultAcronyms options for the objc-property-declaration check have been removed. Improvements to pp-trace * Added a new option -callbacks to filter preprocessor callbacks. It replaces the -ignore option.

yudar1024 · 2019-12-04T03:04:51Z

@HighCommander4 I wanna know weather this spec is finalized? wait this feature long time and an implement pr merge 823 depends on this spec

HighCommander4 · 2019-12-04T03:29:12Z

@yudar1024 I'm not the spec's author, nor a maintainer of this repo. I just implemented the spec in the clangd language server.

My understanding is the spec continues to be subject to change until it merges. However, clients and servers may choose to implement it eagerly (as we did in clangd), with the understanding that if the spec changes the implementation will need to be updated as well.

@nridge

Summary: Patch by Nathan Ridge(@nridge)! This is an LSP extension proposed here: microsoft/vscode-languageserver-node#426 An example client implementation can be found here: eclipse-theia/theia#3802 Reviewers: kadircet, sammccall Reviewed By: kadircet Subscribers: jdoerfert, sammccall, cfe-commits, mgorny, dschaefer, simark, ilya-biryukov, ioeric, MaskRay, jkorous, arphaman, kadircet Tags: #clang Differential Revision: https://reviews.llvm.org/D56370 llvm-svn: 356445

HighCommander4 · 2020-10-13T23:20:14Z

@kittaakos What should I make of this PR being closed? It does not appear to have been merged. Was there a decision to reject it somewhere?

Trias · 2020-11-24T12:42:57Z

I would like you to consider making range optional in the request. This could be used for displaying document level type requests (i. e inheritance chain of the current class).

I would also like to know the status of this proposal, as it seemed to be rather popular.

dbaeumer · 2020-11-24T14:26:40Z

@Trias there is currently no active work happening to support type hierarchies in LSP.

HighCommander4 · 2020-11-24T18:20:14Z

@Trias there is currently no active work happening to support type hierarchies in LSP.

To clarify: is that just because there's no one driving it forward at the moment? Or is it because the LSP maintainers feel there is no value in this feature?

That is, if someone were to dust off this PR, rebase it to be current, and address any outstanding feedback -- would you / other maintainers continue to entertain it?

dbaeumer · 2020-11-25T13:22:04Z

Such a request makes sense in LSP. But please keep in mind that beside having a spec part we need an implementation in a client library and client as well.

Trias · 2020-11-25T15:36:59Z

client meaning vscode? There apparently is already an existing implementation as shown in the first post but in the theia IDE.

HighCommander4 · 2020-11-25T18:28:49Z

We also have a vscode implementation in vscode-clangd.

Based on microsoft/vscode-languageserver-node#426 (review) Signed-off-by: Akos Kitta <[email protected]>

kittaakos mentioned this pull request Oct 15, 2018

[WIP] Proposal for type hierarchy #346

Closed

spoenemann mentioned this pull request Oct 29, 2018

GH-272: Updated the API to support type hierarchies. eclipse-lsp4j/lsp4j#273

Merged

kittaakos force-pushed the type-hierarchy branch from 8cfb275 to 645e470 Compare January 23, 2019 12:35

dbaeumer requested changes Jan 25, 2019

View reviewed changes

kittaakos force-pushed the type-hierarchy branch 2 times, most recently from dcfa9d3 to 3c9550a Compare January 25, 2019 13:24

kittaakos pushed a commit to kittaakos/lsp4j that referenced this pull request Jan 25, 2019

Adjusted the API for textDocument/typeHierarchy.

d9c455f

Based on microsoft/vscode-languageserver-node#426 (review) Signed-off-by: Akos Kitta <[email protected]>

kittaakos mentioned this pull request Jan 25, 2019

GH-296: Extended the protocol with textDocument/callHierarchy. eclipse-lsp4j/lsp4j#297

Merged

Proposal of the type hierarchy protocol extension.

876d7fe

Signed-off-by: Akos Kitta <[email protected]>

kittaakos force-pushed the type-hierarchy branch from 3c9550a to 876d7fe Compare January 28, 2019 08:40

kittaakos pushed a commit to kittaakos/lsp4j that referenced this pull request Jan 28, 2019

Adjusted the API for textDocument/typeHierarchy.

03301fa

Based on microsoft/vscode-languageserver-node#426 (review) Signed-off-by: Akos Kitta <[email protected]>

HighCommander4 reviewed Feb 1, 2019

View reviewed changes

AlexTugarev added a commit to typescript-language-server/typescript-language-server that referenced this pull request Feb 1, 2019

[type-hierarchy] Implement LSP proposal

12aa8ed

See: microsoft/vscode-languageserver-node#426 Signed-off-by: Alex Tugarev <[email protected]>

kittaakos mentioned this pull request Feb 5, 2019

Will Lsp4j Participate in 2019-03 eclipse-lsp4j/lsp4j#301

Closed

sam-mccall reviewed Feb 11, 2019

View reviewed changes

kieferrm mentioned this pull request Feb 19, 2019

Iteration Plan for February 2019 microsoft/vscode#68293

Closed

35 tasks

kittaakos mentioned this pull request Mar 5, 2019

GH-28: Added support for the super- and subtype hierarchies. eclipse-jdtls/eclipse.jdt.ls#823

Closed

AlexTugarev added a commit to typescript-language-server/typescript-language-server that referenced this pull request Mar 6, 2019

[type-hierarchy] Implement LSP proposal

aa0ffc8

See: microsoft/vscode-languageserver-node#426 Signed-off-by: Alex Tugarev <[email protected]>

AlexTugarev mentioned this pull request Mar 6, 2019

[type-hierarchy] Implement LSP proposal (wip) typescript-language-server/typescript-language-server#102

Closed

AlexTugarev added a commit to typescript-language-server/typescript-language-server that referenced this pull request Mar 6, 2019

[type-hierarchy] Implement LSP proposal

5735e3c

See: microsoft/vscode-languageserver-node#426 Signed-off-by: Alex Tugarev <[email protected]>

AlexTugarev added a commit to typescript-language-server/typescript-language-server that referenced this pull request Mar 6, 2019

[type-hierarchy] Implement LSP proposal

26bdf90

See: microsoft/vscode-languageserver-node#426 Signed-off-by: Alex Tugarev <[email protected]>

AlexTugarev added a commit to typescript-language-server/typescript-language-server that referenced this pull request Mar 6, 2019

[type-hierarchy] Implement LSP proposal

dc0a289

See: microsoft/vscode-languageserver-node#426 Signed-off-by: Alex Tugarev <[email protected]>

AlexTugarev added a commit to typescript-language-server/typescript-language-server that referenced this pull request Mar 7, 2019

[type-hierarchy] Implement LSP proposal

cdddb8f

See: microsoft/vscode-languageserver-node#426 Signed-off-by: Alex Tugarev <[email protected]>

AlexTugarev added a commit to typescript-language-server/typescript-language-server that referenced this pull request Mar 8, 2019

[type-hierarchy] Implement LSP proposal

648bfa8

See: microsoft/vscode-languageserver-node#426 Signed-off-by: Alex Tugarev <[email protected]>

kieferrm mentioned this pull request Mar 9, 2019

Iteration Plan for March 2019 microsoft/vscode#70102

Closed

26 tasks

kittaakos mentioned this pull request Mar 13, 2019

[Type Hierarchy] Support servers that want to compute the type hierarchy eagerly eclipse-theia/theia#4540

Closed

HighCommander4 mentioned this pull request Mar 20, 2019

Use all the type hierarchy levels the server sends (fixes #4540) eclipse-theia/theia#4574

Merged

kieferrm mentioned this pull request Apr 5, 2019

Iteration Plan for April 2019 microsoft/vscode#71830

Closed

9 tasks

KamasamaK mentioned this pull request Apr 24, 2019

Create a "TypeHierarchyProvider" api for visualising type hierarchies microsoft/vscode#15533

Closed

jvilk-stripe mentioned this pull request Aug 2, 2019

LSP: Implement type hierarchy protocol extension sorbet/sorbet#1477

Open

rwols mentioned this pull request Mar 20, 2020

Discussion on a simpler C++ user experience sublimelsp/LSP#921

Closed

KamasamaK mentioned this pull request Jul 16, 2020

Feature Request: The CCLS additions imported into the standard microsoft/language-server-protocol#1041

Closed

mashabow mentioned this pull request Jul 30, 2020

2020/07/30 第194回フロントエンドMTG 議事録 feedforce/frontend-meeting#49

Open

kittaakos closed this Sep 11, 2020

HighCommander4 mentioned this pull request Oct 13, 2020

Call Hierarchy microsoft/language-server-protocol#468

Closed

alexet mentioned this pull request Oct 27, 2020

Add type hierarchy support in CodeQL github/vscode-codeql#561

Open

rwols mentioned this pull request Nov 24, 2020

Multi-Document-Information in DocumentSymbolsRequest microsoft/language-server-protocol#1149

Closed

vladdu pushed a commit to vladdu/lsp4j that referenced this pull request Jan 26, 2021

Adjusted the API for textDocument/typeHierarchy.

f8ce4fe

Based on microsoft/vscode-languageserver-node#426 (review) Signed-off-by: Akos Kitta <[email protected]>

HighCommander4 mentioned this pull request Jul 22, 2021

Migrate type hierarchy to official protocol clangd/clangd#826

Closed

This was referenced Sep 23, 2024

Deduced Incomplete Type Hierarchy clangd/clangd#1093

Open

Type hierarchy does not include all super types clangd/clangd#2161

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Proposal of the type hierarchy protocol extension. #426

Proposal of the type hierarchy protocol extension. #426

kittaakos commented Oct 15, 2018 •

edited

Loading

kittaakos commented Jan 23, 2019

dbaeumer Jan 25, 2019

dbaeumer Jan 25, 2019

dbaeumer Jan 25, 2019

dbaeumer Jan 25, 2019

dbaeumer Jan 25, 2019

kittaakos Jan 25, 2019

dbaeumer Jan 25, 2019

kittaakos commented Jan 25, 2019

HighCommander4 Feb 1, 2019

sam-mccall Feb 11, 2019

sam-mccall Feb 11, 2019

HighCommander4 commented Jul 28, 2019

yudar1024 commented Dec 4, 2019

HighCommander4 commented Dec 4, 2019

HighCommander4 commented Oct 13, 2020

Trias commented Nov 24, 2020 •

edited

Loading

dbaeumer commented Nov 24, 2020

HighCommander4 commented Nov 24, 2020

dbaeumer commented Nov 25, 2020

Trias commented Nov 25, 2020

HighCommander4 commented Nov 25, 2020


		_Requests_:

		The `Type Hierarchy Request` is sent from the client to the server to retrieve a `TypeHierarchyItem` at a given cursor position. If computing full type hierarchy items is expensive, servers can additionally provide a handler for the type hierarchy item resolve request (`typeHierarchy/resolve`). This request would also allow to specify if the item should be resolved and whether sub- or supertypes are to be resolved. If no item can be retrieved for a given text document position, returns with `null`.

Proposal of the type hierarchy protocol extension. #426

Proposal of the type hierarchy protocol extension. #426

Conversation

kittaakos commented Oct 15, 2018 • edited Loading

kittaakos commented Jan 23, 2019

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kittaakos commented Jan 25, 2019

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

HighCommander4 commented Jul 28, 2019

yudar1024 commented Dec 4, 2019

HighCommander4 commented Dec 4, 2019

HighCommander4 commented Oct 13, 2020

Trias commented Nov 24, 2020 • edited Loading

dbaeumer commented Nov 24, 2020

HighCommander4 commented Nov 24, 2020

dbaeumer commented Nov 25, 2020

Trias commented Nov 25, 2020

HighCommander4 commented Nov 25, 2020

kittaakos commented Oct 15, 2018 •

edited

Loading

Trias commented Nov 24, 2020 •

edited

Loading