88346e9948
This is based on Paul Jolly's CL 228760, updated to use the new cache API, support the symbolStyle configuration option, and lift up the concept of symbol score for later improvement. From that CL: There are a number of issues with the current implementation: * test variant packages are not handled correctly, meaning duplicate symbols are returned * fuzzy results are not ordered by score We refactor the implementation of workspace symbol to use a symbolCollector that carries context during the walk for symbols. As part of resolving the test variant issue, we first determine a list of packages to walk. (*symbolCollector).collectPackages gathers the packages we are going to inspect for symbols. This pre-step is required in order to filter out any "duplicate" *types.Package. The duplicates arise for packages that have test variants. For example, if package mod.com/p has test files, then we will visit two packages that have the PkgPath() mod.com/p: the first is the actual package mod.com/p, the second is a special version that includes the non-XTest _test.go files. If we were to walk both of of these packages, then we would get duplicate matching symbols and we would waste effort. Therefore where test variants exist we walk those (because they include any symbols defined in non-XTest _test.go files). One further complication is that even after this filtering, packages between views might not be "identical" because they can be built using different build constraints (via the "env" config option). Therefore on a per view basis we first build up a map of PkgPath() -> *types.Package preferring the test variants if they exist. Then we merge the results between views, de-duping by *types.Package. Finally, when we come to walk these packages and start gathering symbols, we ignore any files we have already seen (due to different *types.Package for the same import path as a result of different build constraints), keeping track of those symbols via symbolCollector. Then we walk that list of packages in much the same way as before. For golang/go#40548 Co-authored-by: Paul Jolly <paul@myitcv.io> Change-Id: I8af5bdedbd4a6c3631a213d73a735aea556a13ae Reviewed-on: https://go-review.googlesource.com/c/tools/+/247818 Run-TryBot: Robert Findley <rfindley@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Rebecca Stambler <rstambler@golang.org> |
||
|---|---|---|
| benchmark/parse | ||
| blog | ||
| cmd | ||
| container/intsets | ||
| cover | ||
| go | ||
| godoc | ||
| gopls | ||
| imports | ||
| internal | ||
| playground | ||
| present | ||
| refactor | ||
| txtar | ||
| .gitattributes | ||
| .gitignore | ||
| .prettierrc | ||
| AUTHORS | ||
| codereview.cfg | ||
| CONTRIBUTING.md | ||
| CONTRIBUTORS | ||
| go.mod | ||
| go.sum | ||
| LICENSE | ||
| PATENTS | ||
| README.md | ||
Go Tools
This subrepository holds the source for various packages and tools that support the Go programming language.
Some of the tools, godoc and vet for example, are included in binary Go
distributions.
Others, including the Go guru and the test coverage tool, can be fetched with
go get.
Packages include a type-checker for Go and an implementation of the Static Single Assignment form (SSA) representation for Go programs.
Download/Install
The easiest way to install is to run go get -u golang.org/x/tools/.... You can
also manually git clone the repository to $GOPATH/src/golang.org/x/tools.
JS/CSS Formatting
This repository uses prettier to format JS and CSS files.
The version of prettier used is 1.18.2.
It is encouraged that all JS and CSS code be run through this before submitting a change. However, it is not a strict requirement enforced by CI.
Report Issues / Send Patches
This repository uses Gerrit for code changes. To learn how to submit changes to this repository, see https://golang.org/doc/contribute.html.
The main issue tracker for the tools repository is located at https://github.com/golang/go/issues. Prefix your issue with "x/tools/(your subdir):" in the subject line, so it is easy to find.