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

Jump to bottom

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

Closed
hyangah opened this issue Jul 31, 2020 · 4 comments
Closed

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

hyangah opened this issue Jul 31, 2020 · 4 comments
Labels
FrozenDueToAge gopls Issues related to the Go language server, gopls. Tools This label describes issues relating to any tools in the x/tools repository.
Milestone
gopls/v0.8.0

Comments

@hyangah
Copy link
Contributor

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 Tools This label describes issues relating to any tools in the x/tools repository. gopls Issues related to the Go language server, gopls. labels Jul 31, 2020
@gopherbot gopherbot added this to the Unreleased milestone Jul 31, 2020
@hyangah
Copy link
Contributor Author

hyangah commented Jul 31, 2020

@gopherbot remove Documentation

@hyangah
Copy link
Contributor Author

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

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
@stamblerre stamblerre added this to the gopls/unplanned milestone Oct 21, 2020
@hyangah hyangah mentioned this issue Dec 10, 2020
Closed
@hyangah hyangah mentioned this issue Jul 28, 2021
Open
9 tasks
@gopherbot
Copy link

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

@golang golang locked and limited conversation to collaborators Aug 14, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge gopls Issues related to the Go language server, gopls. Tools This label describes issues relating to any tools in the x/tools repository.
Projects
None yet
Milestone
gopls/v0.8.0
Development

No branches or pull requests
4 participants
@hyangah @stamblerre @gopherbot @findleyr