Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Workspace Hierarchy Request #136

Closed
gorkem opened this issue Nov 26, 2016 · 9 comments
Closed

Workspace Hierarchy Request #136

gorkem opened this issue Nov 26, 2016 · 9 comments
Labels
feature-request Request for new features or functionality implemented new request
Milestone

Comments

@gorkem
Copy link
Contributor

gorkem commented Nov 26, 2016

It is important for object oriented languages to retrieve the inheritance information. I would like to discuss a new request for retrieving hierarchy of a given Symbol.

@felixfbecker
Copy link

felixfbecker commented Nov 29, 2016

Some food for thought: Many languages have a fully qualified structural element name for every symbol. Using such a unique identifier, you could represent the tree like this:

interface SymbolInformation {

  // other properties...

  /** fully qualified structural element name (must be unique) */
  id?: string;

  /** an array of symbol FQSENs that this symbol is a child of in a class hierachy */
  extends?: string[];
}

You would then get the hierarchy from workspace/symbol or textDocument/documentSymbol or any method that returns SymbolInformation.

Whether it extends or implements is inferred from the SymbolKind of the parent since languages like C++ don't have separate keywords for that

@dbaeumer dbaeumer added this to the Backlog milestone Dec 30, 2016
@dbaeumer dbaeumer added the feature-request Request for new features or functionality label Dec 30, 2016
@dbaeumer
Copy link
Member

I agree that a hierarchy request is desirable. We could add this without breaking clients since clients that can't render this will not request it.

@tsmaeder
Copy link

@felixfbecker if we go by the example of Java, fqn's are not unique, neither at development time (check out multiple versions of the same class) nor at runtime (load different versions of the same class twice, in different class loaders).
I belive we need something like extends: SymbolInformation [];
Also, what about subtype hierarchy?

@dbaeumer
Copy link
Member

dbaeumer commented Oct 3, 2017

I worked on contributing proposed protocol more easily. A document describing this is here: https://github.com/Microsoft/language-server-protocol/blob/master/contributing.md

May be someone wants to look into this.

facebook-github-bot pushed a commit to facebookarchive/nuclide that referenced this issue Dec 1, 2017
Summary:
Requires building cquery on branch pelmers/containername-change to look correct.

The LSP specification specifically warns against using documentSymbols containerName fields to create symbol hierarchies but that's exactly what we do in the outline view. In the future I think there would be better ways to do this.
https://github.com/Microsoft/language-server-protocol/blob/master/protocol.md#textDocument_documentSymbol
and discussion at microsoft/language-server-protocol#136

Reviewed By: a20012251

Differential Revision: D6451986

fbshipit-source-id: 9182535584910f82039662951a1d2b9e461b47d8
@gorkem
Copy link
Contributor Author

gorkem commented May 5, 2018

Initial proposal posted microsoft/vscode-languageserver-node#346

@dbaeumer
Copy link
Member

dbaeumer commented May 8, 2018

I added my comments in microsoft/vscode-languageserver-node#346 since it contains a concrete proposal.

@KamasamaK
Copy link
Contributor

The current proposal for this feature is at #1231. Feel free to provide any feedback you might have.

@dbaeumer
Copy link
Member

Type Hierarchy got merged into the LSP libs as proposed.

@dbaeumer dbaeumer modified the milestones: Backlog, 3.17 Oct 26, 2021
@dbaeumer
Copy link
Member

Added to 3.17.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature-request Request for new features or functionality implemented new request
Projects
None yet
Development

No branches or pull requests

5 participants