x/tools/gopls: add gopls.package_symbols command

[jackieli-tes]

gopls version

Build info
----------
golang.org/x/tools/gopls v0.8.0
    golang.org/x/tools/gopls@v0.8.0 h1:a71KO95TfIvCCMQJrZBSQIGQ9lkc0kWL+dSlEdZd7HI=
    github.com/BurntSushi/toml@v1.0.0 h1:dtDWrepsVPfW9H/4y7dDgFc2MBUSeJhlaDtK13CxFlU=
    github.com/google/go-cmp@v0.5.7 h1:81/ik6ipDQS2aGcBfIN5dHDB36BwrStyeAQquSYCV4o=
    github.com/sergi/go-diff@v1.1.0 h1:we8PVUC3FE2uYfodKH/nBHMSetSfHDR6scGdBi+erh0=
    golang.org/x/mod@v0.6.0-dev.0.20220106191415-9b9b3d81d5e3 h1:kQgndtyPBW/JIYERgdxfwMYh3AVStj88WQTlNDi2a+o=
    golang.org/x/sync@v0.0.0-20210220032951-036812b2e83c h1:5KslGYwFpkhGh+Q16bwMP3cOontH8FOep7tGV86Y7SQ=
    golang.org/x/sys@v0.0.0-20220209214540-3681064d5158 h1:rm+CHSpPEEW2IsXUib1ThaHIjuBVZjxNgSKmBLFfD4c=
    golang.org/x/text@v0.3.7 h1:olpwvP2KacW1ZWvsR7uQhoyTYvKAupfQrRGBFM352Gk=
    golang.org/x/tools@v0.1.10-0.20220303153236-fa15af63a6f1 h1:UVkOvSIhR/pX6OflsXS9hsDvaUJn8SLHqTlvdfUDiNo=
    golang.org/x/xerrors@v0.0.0-20200804184101-5ec99f83aff1 h1:go1bK/D/BFZV2I8cIQd1NKEZ+0owSTG1fDTci4IqFcE=
    honnef.co/go/tools@v0.2.2 h1:MNh1AVMyVX23VUHE2O27jm6lNj3vjO5DexS4A1xvnzk=
    mvdan.cc/gofumpt@v0.3.0 h1:kTojdZo9AcEYbQYhGuLf/zszYthRdhDNDUi2JKTxas4=
    mvdan.cc/xurls/v2@v2.3.0 h1:59Olnbt67UKpxF1EwVBopJvkSUBmgtb468E4GVWIZ1I=
go: go1.17.5

go env

GO111MODULE="on"
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/jackieli/.cache/go-build"
GOENV="/home/jackieli/.config/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/home/jackieli/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/jackieli/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/home/linuxbrew/.linuxbrew/Cellar/go/1.17.5/libexec"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/home/linuxbrew/.linuxbrew/Cellar/go/1.17.5/libexec/pkg/tool/linux_amd64"
GOVCS=""
GOVERSION="go1.17.5"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/dev/null"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build1338523989=/tmp/go-build -gno-record-gcc-switches"

What did you do?

I'm developing a vim/neovim plugin that need to retrieve the all the tests of the current package. I would also want to list all the methods of the struct under the cursor.

What work around did you consider?

I tried using DocumentSymbols query to retrieve all the symbols in the current package, then I filter it down. But this doesn't cover methods or tests defined in another file of the same package.

I also tried using the WorkspaceSymbols query and use the package name as prefix, but the package name is not the full import, so the symbols returned could be from another package. E.g. I have a github.com/jackieli-tes/errors.Is and if I filter workspace symbols by ^errors.Is it returns the std's errors.Is

What solution do you want to see?

If #37237 is implemented. I believe all of the above problem should be solved.

Alternatively, most of the queries I'd like to have are all package related. So I propose adding and lsp command:

Identifier: gopls.package_symbols

Query the package symbols of the package a given go file belongs to.

Args:

{
	// The go file URI
	"URI": string,
	// A query string to filter symbols by
	"Query": string
}

The Query can be an exact match or the same as the WorkspaceSymbols query syntax: https://github.com/golang/tools/blob/master/gopls/doc/features.md#symbol-queries

Result:

Result should be same as WorkspaceSymbol[]

Editor and settings

I'm using neovim 0.6.1 with coc.nvim. Using the default instruction from editor section

[findleyr]

As discussed on #37237, it is probably better to implement such a query as a separate query, rather than overloading the WorkspaceSymbols command.

@hyangah @h9jiang I think this could be useful for VS Code as well, as we've discussed enhancing the explorer to include a package outline (compare https://github.com/766b/vscode-go-outliner). Can you comment on whether we'd be able to present a nice package outline in VS Code using this function?

@madelinekalil this may be a good project for you.

[h9jiang]

I think we should be able enhancing the explorer with a package outline.

Since we are discussing explorer, we should also consider when we should render the explorer. The go explorer shows up even for very basic tasks. We might not want to render them when user is not working on go project.

See golang/vscode-go#3616

[findleyr]

From discussion with @h9jiang: we should investigate if we could somehow integrate this with the existing 'Outline' view. Ideally, we'd be able to add an additional setting in the outline menu to toggle between file and package outline.
(while we're there, it would also be nice to nest methods under the type).

@h9jiang is going to investigate if we can extend or replace the 'Outline' panel.

[findleyr]

(@madelinekalil, let's hold off on implementing this in gopls until we have a plan for if/how it can be integrated in VS Code).