documentSymbol method (SymbolInformation) should return tree instead of flat list

[Yanpas]

Currently there is no protocol defined way to build a tree of symbols (e.g. method foo inside class Bar inside package buz). It results that there is no reliable way to build outline of symbols.

SymbolInformation contains location and containerName members.

location's range doesn't have to denote a node range in the sense of a abstract syntax tree

containerName can't be used to re-infer a hierarchy for the document symbols

There should be some parent member or something.

[patrys]

Related discussion: #132

[dbaeumer]

Also related to #136

[rcjsuen]

A new hierarchical outline has been added in VS Code .

What does this mean for the LSP?

[dbaeumer]

Either we have a second request or we add a second return type to the existing one. Something like Hierarchy<SymbolInformaiton>

[dbaeumer]

A first cut can be found here: https://github.com/Microsoft/vscode-languageserver-node/tree/dbaeumer/373

FYI @rcjsuen @mickaelistria @tsmaeder @gorkem

[dbaeumer]

Feedback appreciated.

[rcjsuen]

@dbaeumer Thanks, Dirk. I took a quick look at your commit.

I wonder if the detail field should be optional instead? I guess it can also be an empty string? For a simple class declaration the name is simply going to be MyClass and there won't be any additional details, correct?

Also, the idea is that the response to a textDocument/documentSymbol will now be DocumentSymbol | SymbolInformation[] | null, correct?

[dbaeumer]

@rcjsuen Yes, the idea is that the reponse returns

DocumentSymbol[] | SymbolInformation[] | null

Note that it is DocumentSymbol[]. Reason being is that I am not a fan of an artificial root node for the file which in some languages will not represent a symbol.

[dbaeumer]

Making the details optional makes sense to me as well. Will make the change since an empty string is not better.

[kittaakos]

From the 3.10.0 changelog:

Add support for hierarchical document symbols as a valid reponse to a textDocument/documentSymbol request.

Isn't it already supported by the protocol?

(Sorry for the noise, if no.)

[Yanpas]

Yes, seems to be already implemented with new outline feature in vs code

[dbaeumer]

@kittaakos thanks for pointing this out.