Support Type Hierarchy #1231

CsCherrYY · 2021-03-29T10:40:35Z

There are three requests to support type hierarchy:

textDocument/prepareTypeHierarchy: Sent from the client to the server to get the type hierarchy item from the given text document position
typeHierarchy/supertypes and typeHierarchy/subtypes: Sent from the client to the server to resolve the given item's supertypes or subtypes

KamasamaK · 2021-03-30T09:23:16Z

_specifications/specification-3-17.md

+	 *
+	 * @since 3.17.0
+	 */
+	typeHierarchyProvider?: boolean | TypeHierarchyOptions


Is a simple boolean necessary/sufficient here since each server capability can be defined under TypeHierarchyOptions?

Yeah, we don't need boolean here in this version. We are considering whether to remove the capability inheritanceTreeSuppport to keep the type hierarchy general. I'll update this PR then.

I find it was referring call hierarchy.

callHierarchyProvider?: boolean | CallHierarchyOptions | CallHierarchyRegistrationOptions;

which is equivalent to:

boolean // simplest OR { workDoneProgress?: boolean; // from WorkDoneProgressOptions } OR { workDoneProgress?: boolean; // from WorkDoneProgressOptions id?: string; // from StaticRegistrationOptions documentSelector: DocumentSelector | null; // from TextDocumentRegistrationOptions }

specifying whether server has capabitility to support work done progress / unregistration / customized scope of the feature.

Is a simple boolean necessary/sufficient here since each server capability can be defined under TypeHierarchyOptions?

@KamasamaK I think boolean is insufficient for advanced features mentioned above. For me, it's somehow necessary . Because on one hand, when I implement it in server side I might not care about any advanced feature, then I can simply return a true; on the other hand it's consistent with other capabilities like call hierarchy.

We are considering whether to remove the capability inheritanceTreeSuppport to keep the type hierarchy general.

@CsCherrYY I'm voting +1 for removing inheritanceTreeSuppport, otherwise for languages supporting multiple inheritance (e.g. C++), you may also need something like inheritanceGraphSuppport?

If you don't care about implementing or can't implement advanced features, you can return false for their capabilities. For example, codeLensProvider only has a type of CodeLensOptions with one optional native capability, so that's already established for LSP. That is the reason I say it is probably unnecessary. But if the extra capability is going to be removed, that might change things.

Perhaps @dbaeumer can weigh in on the necessity of a simple boolean for new operations when *Options exists, and whether them having no or only optional native properties makes a difference in that determination.

Thank you for pointing out CodeLensOptions. It looks:
{ resolveProvider: false } means server doesn't have a resolve provider.
{ resolveProvider: true } means server also support to resolve code lens.
So now I have a question, if server doesn't support code lens at all, what should it return? (if boolean is not allowed)

Excluding codeLensProvider would indicate that the server does not support it.

A missing property should be interpreted as an absence of the capability. If a missing property normally defines sub properties, all missing sub properties should be interpreted as an absence of the corresponding capability.

KamasamaK · 2021-03-30T09:24:17Z

_specifications/specification-3-17.md

+_Response_:
+
+* result: `TreeItem<TypeHierarchyItem> | null`
+* error: code and message set in case an exception happens during the 'typeHierarchy/resolve' request


Is this supposed to be 'typeHierarchy/inheritanceTree'? There is no 'typeHierarchy/resolve' request defined.

Yes. I'll fix it in the next commit.

puremourning · 2021-03-30T09:25:41Z

_specifications/specification-3-17.md

+```typescript
+export interface TypeHierarchyOptions extends WorkDoneProgressOptions {
+	/**
+	 * The server has support for supporting inheritance tree.


"support for supporting" -> "support for providing an"

puremourning · 2021-03-30T09:27:10Z

_specifications/specification-3-17.md

+
+_Response_:
+
+* result: `TypeHierarchyItem[] | null` defined as follows:


Why should we allow null here ? What's the client expected to do with a null? It's better to define this to either return an empty array, or an error. Alternatively explicitly define what the meaning of null is (as opposed to an empty array or an error return).

In the textDocument/prepareTypeHierarchy request, if the element in the location of the params is not a valid type (that depends on the server implementation, whether to infer a valid type), it will return null to indicate that there is no result. For those types have no subtypes in typeHierarchy/subtypes, the server will return an empty array.

Thanks for the comment, I'll add a description in the next commit.

null is for consistency since lots of LSP requests that return and array can return null to indicate no elements

puremourning · 2021-03-30T09:28:53Z

_specifications/specification-3-17.md

+
+	/**
+	 * A data entry field that is preserved between a call hierarchy prepare and
+	 * incoming calls or outgoing calls requests.


"and incoming calls or outgoing calls requests" - I'm not sure I understand what that's saying.

It's copy/pasted from CallHierarchyItem.data and mistakenly unchanged.

puremourning · 2021-03-30T09:30:42Z

_specifications/specification-3-17.md

+```
+_Response_:
+
+* result: `TypeHierarchyItem[] | null`


again, what's null for? we need to be explicit about what the valid responses are and what they mean, so that client and servers work together in harmony.

puremourning · 2021-03-30T09:30:53Z

_specifications/specification-3-17.md

+```
+_Response_:
+
+* result: `TypeHierarchyItem[] | null`


what does null return mean?

puremourning · 2021-03-30T09:31:59Z

_specifications/specification-3-17.md

+```
+_Response_:
+
+* result: `TreeItem<TypeHierarchyItem> | null`


What does null mean?

puremourning · 2021-03-30T09:36:14Z

_specifications/specification-3-17.md

+
+_Request_:
+
+* method: 'typeHierarchy/subtypes'


It's not obvious why there are so many messages here, nor why the prepare and resolve steps are required.

For clients (and presumably many servers), it would be simpler to return the whole tree in a single message. With this current API proposal there will be a lot of chatter for an ostensibly simple dataset. Could we perhaps incorporate the ability for the server to return the full type hierarchy in response to just a simple /typeHierarchy message as the first instance? Do we know that this is extremely expensive to calculate in many servers (enough to justify the complexity of this back-and-forth prepare/request/request/request API?

It's also unclear to me when a client should use subtypes and super types requests vs the inheritanceTree request - unless I'm missing something, they are implementing the same thing in a different way? What's the rationale for this?

Just as you mentioned, calculating the full type hierarchy is extremely expensive for a given type with many subtypes. We currently have an implementation in Java language server, it may cost about 25 seconds to calculate the direct subtypes of java.io.Serializable (1877 subtypes in the example project in total). We want the user to know what server is doing - after prepare request, the client can get the base type itself so that it can be shown. So the user can see the based type with some progress icons at least, with partial result mechanism (if implemented), the client can show the results gradually.

For the second question, we have two common views for all languages, they are subtypes and supertypes. For single inheritance languages, since a given class could only have one superclass, usually they have another view to show all the classes in the inheritance tree. That can be performed in many supertypes requests and a subtypes request as well, so we're still in discussing whether to isolate this request.

CsCherrYY · 2021-04-13T09:27:25Z

Thanks a lot for the comments from @KamasamaK @puremourning and @Eskibear , I have the following thinking and plan about updating this PR.

Address the wording issues and mistakes you have mentioned.
Remove typeHierarchy/inheritanceTree to make it general with both single inheritance languages and multiple inheritance languages, the support of inheritance tree could be implemented in clients.
Remove hasSupertypes and hasSubtypes to keep the interface simple. The clients would keep the status of each item.
As @puremourning said, it would be indeed simpler if we can return the full type hierarchy in one request, but performance issue is still crucial. Could we have a property naming like depth or level to indicate the resolve levels in the server? That allows the client to clear the resolve levels in one request. Since we're using partial result mechanism and the return type of typeHierarchy/supertypes or typeHierarchy/subtypes is an array, I have no promising idea to define a good data structure of the return array including more than one level of type hierarchy. Could we find a proper one?

Do you have any suggestions or comments?

CsCherrYY · 2021-04-20T08:11:13Z

Based on current typeHierarchy/supertypes and typeHierarchy/subtypes requests, it's still useful for single inheritance languages(C#, Java, etc.) to support inheritance tree view, so we have a draft to support inheritance tree view without changing current requests:

in TypeHierarchyOptions, inheritanceTreeSuppport can be used to indicate if the language server has support for inheritance tree.
```
export interface TypeHierarchyOptions extends WorkDoneProgressOptions {
    /** 
     * The server supports for providing an inheritance tree.
     */
    inheritanceTreeSuppport?: boolean;
}
```
Client can offer an inheritance tree view if inheritanceTreeSuppport is true.
in TypeHierarchySupertypesParams, to distinguish between general typeHierarchy/supertypes requests and the typeHierarchy/supertypes requests during inheritance tree view initialization, classOnly is used to tell server if the request should only return class:
```
export interface TypeHierarchySupertypesParams extends
    WorkDoneProgressParams, PartialResultParams {
    item: TypeHierarchyItem;
    /**
     * This request only asks for super class of the given type.
     */
    classOnly?: boolean;
}
```
In inheritance tree view, client will send multiple typeHierarchy/supertypes requests with its classOnly set to true, the request will return super class of the given item. Based on this, client could get all ancestor classes of base type in the inheritance tree. Another typeHierarchy/subtypes request will be sent to get direct subtypes of base type in the initialization stage.

Does this make sense?

jakebailey · 2021-04-26T20:37:41Z

_specifications/specification-3-17.md

+  1. first a type hierarchy item is prepared for the given text document position.
+  1. for a type hierarchy item the supertype or subtype type hierarchy items are resolved.
+
+In the first step, the `textDocument/prepareTypeHierarchy` request could have a unique, constant and optional `transactionId`. The following `typeHierarchy/supertypes` and `typeHierarchy/subtypes` requests in the second step could have the same `transactionId` in their params, which could be used to help indicate some cached data in the server.


I'm not aware of any existing LSP API that uses this "prepare to get ID then pass ID back" method; this seems pretty specific to a particular LS implementation. The closest I'm aware of is completion (where it's arbitrary data), but that's because the user may not even visit a particular completion (so you want to defer that work to later in hopes it's never done). This new API appears to always call prepare, then one of the two other calls.

Why not just have the two calls and cache the information internally (say, per snapshot or similar?). This would match other similarly-expensive calls like go-to-references or go-to-implementations which are simple requests. If we were to add this to Pylance, we wouldn't need this transaction ID, as the info is there in the analysis (or will be lazily produced from the current state)

I can also see this pattern being problematic for LSIF (where you expect basically pure functions for read-only requests), but I guess the ID is optional.

this "prepare to get ID then pass ID back" method

As far as I understand of this proposal, client is reponsible to generate this ID itself, and passes it to server in request textDocument/prepareTypeHierarchy. I assume the purpose of this "prepare" request is to get corresponding TypeHierarchyItem of the cursor position where you send the request, instead of getting ID.

As mentioned above in https://github.com/microsoft/language-server-protocol/pull/1231/files#r612267620 (though not explicitly described in spec) if it's not a valid type (e.g. triggered on some keywords), response of "prepare" request can be null, and client probably should not send further requests then.

I can sort of see the argument of needing to re-query at various points in the same hierarchy, but I can see troubles where because the client is defining this ID, it doesn't have enough information to determine when the result has actually changed (e.g., the server has changed the analysis and now this request cycle is invalid; like on an external file watcher change), and therefore requires something like how semantic tokenization has notifications for "the data has changed".

One thing that I think is similar to this right now is signature help retriggering; as the user moves the cursor, the previous signature info is passed back to the server, which can then use that to further edit the response, or, choose to ignore it and give the data fresh.

I guess I'll need to reread this with fresh eyes in the morning.

Here is an alternative approach: the prepare request returns a TypeHierarchyItem so the data field of the item can be used to identify the type hierarchy. If the type hierarchy changes I would suggest that the server errors this on the next sub or super type request and lets the client decided what to do (e.g. refresh the hierarchy, close the hierarchy, ...)

Yeah, I find that to be a bit more understandable and close to completion resolution / signature help callbacks (assuming this new data field is something returned by the server at the prepare call, then passed back by the client, versus how this spec currently has the client come up with an ID).

Here is an alternative approach: the prepare request returns a TypeHierarchyItem so the data field of the item can be used to identify the type hierarchy.

So under this approach, in my understanding, the server will be responsible for managing the "transaction" itself. It can save something to identify it in data field at the response of prepare call, as @jakebailey said. The client always keep it unchanged in the TypeHierarchyItem and send it back with the next sub or super type requests, is that right?

And if we apply this and remove transactionId in params, should we add some description explicitly to show that the data field could be used to carry the type hierarchy related information in the server? I think it may help the designers of language servers if the server can use this mechanism to improve the performance.

@CsCherrYY yes, that is the idea and consistent with other situations. For example the completion item has a data field as well which the clients needs to preserve and sent back on a resolve call so that the server can related the completion item to some previous request.

A comment in the data field that describes the use case of a transaction ID is for sure something we should do.

CsCherrYY · 2021-05-07T09:15:07Z

I have updated the PR based on @dbaeumer 's comment and remove transactionId. Besides, the inheritanceTreeSuppport is added as a server capability in this commit as well, the draft is mentioned in #1231 (comment).

jakebailey · 2021-05-07T18:20:14Z

_specifications/specification-3-17.md

+	 * type hierarchy in the server, helping improve the performance on 
+	 * resolving supertypes and subtypes.
+	 */
+	data?: unknown;


Would it make more sense for the prepare response to be an object (versus an array), and have a single data field? I guess I'm not sure to what extent the full call needs data versus each individual item (where if you really just wanted the same data, you'd have to dupe it on each of them).

FWIW, in clangd, what we put in the data field is a hash of the internal universal identifier of the symbol represented by the TypeHierarchyItem, so it being per-item makes sense.

I think if we need a data field in each individual item would depend on server. If server could hold or cache the whole type hierarchy and use it to find a type in coming requests, one data field is OK, but if server wants to use data field to indicate the specific type, we'd better to keep a data field in each item. In protocol, I suggest keeping this field in each item to support these two usages both.

Eskibear · 2021-05-17T06:43:16Z

_specifications/specification-3-17.md

+	/** 
+	 * The server supports for providing an inheritance tree.
+	 */
+	inheritanceTreeSuppport?: boolean;


typo in support

I am not convinced that we should add inheritanceTreeSuppport in the first version since I don't see clients to support this rendering. IMO it makes things simply harder to understand. Or do I miss something?

My apologize for not mentioning the client behaviors about inheritanceTreeSupport in the protocol. I'd like to describe it in detail here:

When using inheritanceTreeSupport, the client has the same mechanism of handling response data as the other two requests. The only difference is how to set classOnly in TypeHierarchySupertypesParams.

If the server doesn't set inheritanceTreeSupport or it's false, the classOnly will always be undefined since the server doesn't support inheritance tree. Besides, Inheritance Tree button will hide in the client.

When the server set inheritanceTreeSupport to true, the client could show Inheritance Tree button.

If the active view is inheritance tree view, after prepare request, to get the most ancestor class of the given type, the client will send several typeHierarchy/supertypes requests with classOnly in their params set to true. The responses include all classes in the inheritance tree of the given item, so that the client can render this tree reversally. The remaining requests work normally.

If the active view is not inheritance tree view, classOnly will always be false and everything works normally.

In the server, if there is a typeHierarchy/supertypes request with its classOnly is true, the response should contain class only, otherwise it contains all types.

If there is no inheritanceTreeSupport in the protocol, since we'd like to support inheritance tree view for it's the most important type hierarchy view for Java users (might also for single inheritance language users), we have to independently implement the view in java extension instead. We might make it as a command and use workspace.executeCommand to trigger this view. In server, we'll have the similar logics to handle the supertype requests which return only class. Another concern is that if we can put the Inheritance Tree button properly. See the following screenshot:

Currently we could put them together since we contribute ms-vscode.references-view, if the right two buttons are supported in LSP and implemented in client already, can we still find a way to put them together?

What do you think of this?

I was incorrect about what I said. I see the rendering but I am still not convinced for the modes in the API. Explaining this is simply too complicated. Why can a client not render that tree using the existing API by filtering interfaces. And what do we expect that happens if a client calls the API with classOnly for a item that represents a interface.

Why can a client not render that tree using the existing API by filtering interfaces.

A client can render that tree by filtering interfaces indeed. It's a good tradeoff to remove classOnly and put all the logics in client implementation to keep the protocol clear. If we remove classOnly and keep inheritanceTreeSupport in the first version, should we define the behaviors of client? If we remove inheritanceTreeSupport from the first version, my concern is whether we can still keep the inheritance tree view (from java extension) and the other two views button (from VSCode) together.

And what do we expect that happens if a client calls the API with classOnly for a item that represents a interface.

Currently we expect calling the API with classOnly for an interface will return an empty array since never a class can be the supertype of an interface.

I am not understanding why inheritanceTreeSupport can influence how a client can renderer a class hierarchy. Isn't this something that is under the sole control of the client and a server should never influence this?

Another problem I see with classOnly is that it is specific for a certain use case. It might cause problems with other languages. I could for example imagine a special view for language that have multiple class inheritance. Another view could be special for interface to see the implemented protocols.

If we think that that performance and payload size is a problem then we should add a filter property to the params which would allows to filter hierarchy items on the server side. IMO classOnly is simply to specific for a specific use case.

About inheritanceTreeSupport

After reading through above comments, I think current naming is causing confusion. Let me help to clarify according to my understanding:

ServerCapabilities.inheritanceTreeSupport proposed by @CsCherrYY indicates whether "the language only supports single inheritance through class". E.g. it's true for Java because multiple inheritance is supported through interfaces. And it's false for C++. (@CsCherrYY correct me if I'm wrong)

"how a client can renderer a class hierarchy" mentioned by @dbaeumer should be related to a Client capability if needed. For example inheritanceTreeSupport, inheritanceGraphSupport (for multiple-inheritance languages?) etc. (@dbaeumer correct me if I'm wrong)

About classOnly

If we think that that performance and payload size is a problem then we should add a filter property to the params

Agree that classOnly is merely a specific filter property, is there any other filtering requirement (e.g. interfaceOnly), how would a generic filter property look like?
I'm testing this proposal on Java language server, so far I don't see any performance/payload size problems as we expand the hierarchy level by level, and I'm fine to filter items on either server/client side.

Here I only have a stupid question as I know little about client implementation details: No matter what the filtering property eventually is, if I want to support showing class view (e.g. using tree items in vscode's reference view) for Java, how does client know when to filter the items or not? Does it provide multiple entries (e.g."show supertypes", "show subtypes", "show class view", "show interface only") and send requests with different params corresponding to the entries?

Filter properties would be properties that are available on a TypeHierarchyItem. I would say typically the kind property.

Regarding the UI: it could either be a different command or some sort of filter buttons in the UI.

If it's possible to keep the Class Hierarchy view available for the Java users, I'm very glad to remove inheritanceTreeSupport in the first version since it's indeed a little complicated. Here is another approach to support Class Hierarchy: The Java extension can contribute another button in reference-view and use a separated command to show class hierarchy. But there is still a concern about the UI implementation.

We want to make the separated class hierarchy button align with the two existing type hierarchy buttons (supertype hierarchy and subtype hierarchy). In the current reference-view implementation, the call hierarchy uses context value to control whether to show the button. Since the call hierarchy has only two views, it works well. But for type hierarchy, can we make the context value extendable to support possible other views? Then we can use other conditions like enablement to show if this button is disabled, like the current Java implementation.

@dbaeumer Could you give any suggestions?

Update: Another concern is about the default view. Currently the default type hierarchy view for java users is Class Hierarchy view, which is most frequently used by java developers. However, the implementation of type hierarchy in vscode-references-view would be based on the protocol, supporting subtype hierarchy view and supertype hierarchy view only. Could it be possible to change the default view of type hierarchy in another extension? e.g. Java extension.

Signed-off-by: Yan Zhang <yanzh@microsoft.com>

Eskibear · 2021-05-31T06:46:25Z

I tried implementing current "prepare/supertypes/subtypes" proposal for Java on VS Code. Below is a demo based on type B1.

lsp-based-type-hierarchy_demo.mp4

Eskibear · 2021-05-31T08:26:13Z

About performance and payload, I tested with interface java.io.Serializable which has ~1800 subtypes, it took 5-7s for the subtypes request. And it took ~60s to fetch subtypes of java.lang.Object, i.e. all types including anonymous ones.

lsp-based-type-hierarchy_serializable.mp4

Above was tested on Intel Core i7-10700. Server implementation depends on how powerful the CPU is, e.g. the Serializable case took ~20s for another machine with Intel Xeon E5-1620 v4 (less powerful).

rcjsuen

For typeHierarchy/supertypes and typeHierarchy/subtypes, should the request parameters use something simpler than a TypeHierarchyItem. Is it necessary to include range and selectionRange when asking the server to fetch this information?

CsCherrYY · 2021-06-01T02:06:24Z

For typeHierarchy/supertypes and typeHierarchy/subtypes, should the request parameters use something simpler than a TypeHierarchyItem. Is it necessary to include range and selectionRange when asking the server to fetch this information?

range and selectionRange could be used to specify the particular type in the server. In some cases, like resolving anonymous types in Java, we can't use only name, uri and detail to find the exact type. (Another way is to use data field to preserve some identifier, but data is not a required field)

dbaeumer · 2021-06-03T09:07:50Z

@rcjsuen I was thinking the same but IMO this doesn't cause a lot of overhead and keeps the spec simpler. We don't need to define another type.

Regarding anonymous types: I think this are best identified using the data property on an item.

@CsCherrYY the performance is mainly influenced by the server producing the data. Not by sending them to the client. Right?

CsCherrYY · 2021-06-07T05:20:16Z

@CsCherrYY the performance is mainly influenced by the server producing the data. Not by sending them to the client. Right?

Yes. The time for producing the data in the server takes up major time. I just tried @Eskibear 's implementation on my PC.

For java.io.Serializable (1877 subtypes), the total time to receive the response of java/subtypes is 23172ms, the time when producing the data in the server is 23082ms, which takes up about 99.6% of total time.

For java.util.List (37 subtypes), the total time to receive the response of java/subtypes is 2191ms, the time when producing the data in the server is 2176ms, which takes up about 99.3% of total time.

dbaeumer · 2021-06-07T08:49:17Z

@CsCherrYY thanks for clarification.

dbaeumer · 2021-06-15T06:34:50Z

@CsCherrYY as a next step we should add an implementation of the type hierarchy to the LSP client libraries for VS Code.

CsCherrYY · 2021-06-15T07:13:33Z

@CsCherrYY as a next step we should add an implementation of the type hierarchy to the LSP client libraries for VS Code.

Sure. If we implement this protocol without inheritanceTreeSupport, there are still some concerns about the implementation, as I posted previously in #1231 (comment) and #1231 (comment):

For the UI: We would like to find a proper way to make the class hierarchy view button (will be contributed by Java extension) align with the supertype view button and subtype view button.
For the default view: We would like to make it possible to change the default view if the user is currently using Java extension.

@Eskibear is working on corresponding implementation for LSP client libraries already. I think we can focus on the implementation once we have resolved these concerns.

dbaeumer · 2021-06-18T07:24:35Z

@CsCherrYY regarding #1231 (comment)

To my understanding this is a problem with the reference view. It has nothing to do with what we define in the protocol. Right?

If this is true then we need to discuss the button problem with the VS Code team and might need to think about a PR against https://github.com/Microsoft/vscode-references-view.

CsCherrYY · 2021-06-18T07:57:31Z

@CsCherrYY regarding #1231 (comment)

To my understanding this is a problem with the reference view. It has nothing to do with what we define in the protocol. Right?

If this is true then we need to discuss the button problem with the VS Code team and might need to think about a PR against https://github.com/Microsoft/vscode-references-view.

Yes, they are UI related problems and I'll create an issue to talk about this in the vscode repository.

CsCherrYY · 2021-06-18T10:19:23Z

@dbaeumer I have removed the part about inheritanceTreeSupport in 90090af and create microsoft/vscode#126666, we can discuss the UI problems there.

isc-bsaviano · 2021-09-27T15:31:14Z

What is the status of this PR? The TypeHierarchy API in VS Code is getting finalized for the upcoming release and the PR implementing this in vscode-languageserver-node was merged a while ago

dbaeumer · 2021-09-28T14:40:51Z

We will have a new propsed version of the libs beginning of October. Depending on the feedback there might be changes. When we have some confidence that all is good I will copy the MD part from the implementation to the spec. I would like to keep the PR open to not forget this.

KamasamaK · 2021-12-14T00:39:23Z

Type Hierarchy has already been finalized for VS Code. Is anything still pending for this PR?

dbaeumer · 2021-12-14T10:30:58Z

I wanted to wait with merging the spec to see if there is some feedback about the proposed implementation which is available since a while in the VS Code libs.

KamasamaK · 2022-03-21T08:00:55Z

This was added to the spec in 7201ba1

KamasamaK · 2022-04-06T18:46:14Z

@dbaeumer Since you already committed this feature yourself, this PR is no longer needed.

dbaeumer · 2022-04-07T06:31:24Z

Correct. Will close the PR

CsCherrYY added 2 commits March 29, 2021 18:38

Add support for type hierarchy

4c847a4

fix punctuation

a2be815

KamasamaK reviewed Mar 30, 2021

View reviewed changes

puremourning reviewed Mar 30, 2021

View reviewed changes

KamasamaK mentioned this pull request Apr 13, 2021

Workspace Hierarchy Request #136

Closed

CsCherrYY added 2 commits April 14, 2021 14:24

update and address comments

21db26e

modify the description of prepare type hierarchy request

d4cc98e

jakebailey reviewed Apr 26, 2021

View reviewed changes

CsCherrYY added 2 commits May 7, 2021 17:04

remove transaction ID and add inheritanceTreeSupport capability

2aa99a1

remove unnecessary property type

03ee936

jakebailey reviewed May 7, 2021

View reviewed changes

DanTup mentioned this pull request May 10, 2021

Type Hierarchy should be display in sidebar and provide editor context menu Dart-Code/Dart-Code#3313

Closed

Eskibear reviewed May 17, 2021

View reviewed changes

Eskibear added a commit to Eskibear/vscode-languageserver-node that referenced this pull request May 17, 2021

protocol definition for microsoft/language-server-protocol/pull/1231

0bcee33

Signed-off-by: Yan Zhang <yanzh@microsoft.com>

fix typo

8cab387

rcjsuen reviewed May 31, 2021

View reviewed changes

kieferrm mentioned this pull request Jun 14, 2021

Iteration Plan for June 2021 microsoft/vscode#126181

Closed

72 tasks

remove inheritanceTreeSupport

90090af

CsCherrYY mentioned this pull request Jun 18, 2021

Type Hierarchy Implementation in reference-view microsoft/vscode#126666

Closed

Eskibear mentioned this pull request Jun 22, 2021

Add type hierarchy support microsoft/vscode-languageserver-node#779

Merged

4 tasks

Eskibear mentioned this pull request Jul 14, 2021

add type hierarchy provider microsoft/vscode#128667

Merged

HighCommander4 mentioned this pull request Jul 22, 2021

Migrate type hierarchy to official protocol clangd/clangd#826

Closed

dbaeumer added this to the 3.17 milestone Sep 28, 2021

dbaeumer added the implemented label Nov 2, 2021

CsCherrYY mentioned this pull request Dec 14, 2021

Allow extensions to publish beta releases and users to opt-in to them microsoft/vscode#15756

Closed

dbaeumer closed this Apr 7, 2022


		_Response_:

		* result: `TypeHierarchyItem[] \| null` defined as follows:

Support Type Hierarchy #1231

Support Type Hierarchy #1231

Conversation

CsCherrYY commented Mar 29, 2021 • edited Loading

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

KamasamaK Mar 30, 2021 • edited Loading

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

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

CsCherrYY commented Apr 13, 2021

CsCherrYY commented Apr 20, 2021 • edited Loading

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

CsCherrYY Apr 29, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

CsCherrYY commented May 7, 2021

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

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

About inheritanceTreeSupport

About classOnly

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Eskibear commented May 31, 2021

Eskibear commented May 31, 2021

rcjsuen left a comment

Choose a reason for hiding this comment

CsCherrYY commented Jun 1, 2021

dbaeumer commented Jun 3, 2021

CsCherrYY commented Jun 7, 2021

dbaeumer commented Jun 7, 2021

dbaeumer commented Jun 15, 2021

CsCherrYY commented Jun 15, 2021

dbaeumer commented Jun 18, 2021

CsCherrYY commented Jun 18, 2021 • edited Loading

CsCherrYY commented Jun 18, 2021 • edited Loading

isc-bsaviano commented Sep 27, 2021

dbaeumer commented Sep 28, 2021

KamasamaK commented Dec 14, 2021

dbaeumer commented Dec 14, 2021

KamasamaK commented Mar 21, 2022

KamasamaK commented Apr 6, 2022

dbaeumer commented Apr 7, 2022

CsCherrYY commented Mar 29, 2021 •

edited

Loading

KamasamaK Mar 30, 2021 •

edited

Loading

CsCherrYY commented Apr 20, 2021 •

edited

Loading

CsCherrYY Apr 29, 2021 •

edited

Loading

CsCherrYY commented Jun 18, 2021 •

edited

Loading

CsCherrYY commented Jun 18, 2021 •

edited

Loading