x/tools/gopls: supply imported package names in documentSymbol results

[hyangah]

I want to replace vscode-go's existing DocumentSymbolsProvider with gopls.

The extension currently uses the go-outline tool to extract the document symbol information
and uses it for various purposes (creating codelenses, generate test functions, call other tools, etc).
Even though I think most of them will be eventually replaced with gopls and the extension itself
does not have to retrieve the information directly, I still think it's useful for the extension to access
the info, and possibly relay the info to other extensions (e.g. golang/vscode-go#404)

Looking into gopls's responses and implementation, it looks like the response currently
includes functions and variables declarations.

The existing vscode-go provider provides imported package names. The names are used
when checking the file depends on a package of interest - e.g. whether the test file imports
a popular test framework?

Not sure how the LSP's symbol kinds map to Go's type. For reference -
he following is the currently used mapping by vscode-go's existing symbol provider.

const goKindToCodeKind: { [key: string]: vscode.SymbolKind } = {
	package: vscode.SymbolKind.Package,
	import: vscode.SymbolKind.Namespace,
	variable: vscode.SymbolKind.Variable,
	constant: vscode.SymbolKind.Constant,
	type: vscode.SymbolKind.TypeParameter,
	function: vscode.SymbolKind.Function,
	struct: vscode.SymbolKind.Struct,
	interface: vscode.SymbolKind.Interface
};

[hyangah]

@gopherbot remove Documentation

[hyangah]

Experimented a bit and I am now unsure if this is desirable. Including the imported packages pollute the Outline view.

Looking further, I learned that vscode-go's existing document symbol provider supports two modes (include or exclude imports). Unfortunately, we have no control when using LSP.

Is there any other LSP feature that allows to retrieve the import information?

I also noticed the vscode-go's symbol provider has Package kind as the root symbol, and all symbols in the document are children of it. So, we also know the package name. On the other hand, gopls lists all top level function/declaration in the top level.

[stamblerre]

Is there any other LSP feature that allows to retrieve the import information?

Not that I can think of off the top of my head. There may be something in the spec that I'm missing, or maybe we can implement a custom command.

So, we also know the package name. On the other hand, gopls lists all top level function/declaration in the top level.

We can adjust this in gopls if we want to include the package name. Not sure if the additional nesting is worth it though.

[gopherbot]

Change https://golang.org/cl/383354 mentions this issue: internal/lsp: add ListImports