Commit Graph

2 Commits

Author SHA1 Message Date
Rob Findley ea3a2cdbfb internal/lsp/source: support some fzf-like tokens in symbol matching
It's useful to be able to switch between case sensitive, case
insensitive, and fuzzy matching for symbol without having to reload
gopls. FZF has some nice syntax for this:
  https://github.com/junegunn/fzf#search-syntax

Adopt a subset of this syntax for our symbol search:
  ' for exact matching
  ^ for prefix matching
  $ for suffix matching

It would be straightforward to also support inversion, using
'!', but I deemed this unnecessary.

I think we should adopt this, since none of these symbols conflicts with
Go identifiers, or (AFAIK) with special syntax in major LSP clients.

Change-Id: If2e4d372d4a45ace5ab5d4e76c460f1dcca0bc2b
Reviewed-on: https://go-review.googlesource.com/c/tools/+/248418
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
2020-09-08 16:35:05 +00:00
Robert Findley 88346e9948 internal/lsp: refactor workspace Symbol method
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>
2020-08-27 18:13:30 +00:00