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

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

Open
hyangah opened this issue Jul 31, 2020 · 3 comments
Open

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

hyangah opened this issue Jul 31, 2020 · 3 comments
Labels

Comments

@hyangah
Copy link
Contributor

@hyangah hyangah commented Jul 31, 2020

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
};
@gopherbot gopherbot added this to the Unreleased milestone Jul 31, 2020
@hyangah
Copy link
Contributor Author

@hyangah hyangah commented Jul 31, 2020

@gopherbot remove Documentation

@hyangah
Copy link
Contributor Author

@hyangah hyangah commented Jul 31, 2020

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

image

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
Copy link
Contributor

@stamblerre stamblerre commented Aug 4, 2020

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.

@stamblerre stamblerre removed this from the Unreleased milestone Aug 4, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants
You can’t perform that action at this time.