x/tools/gopls: workspace symbol results appear imprecise and unstable #50016
Comments
myitcv
added
NeedsInvestigation
gopherbot
added
the
Tools
|
Thanks for the report -- it looks clearly like we're not scoring the final path component well enough. Do you have any settings altering the default behavior of workspace symbols? |
From the log I included, I think these are the relevant ones? |
|
Right, I could have looked at the log :) Yes, those are the settings in question, thanks. |
No worries at all. I actually stopped short of trying to detail the settings in the original description because I knew the log would do a better job! |
|
Change https://golang.org/cl/376360 mentions this issue: |
|
Change https://golang.org/cl/376362 mentions this issue: |
|
Change https://golang.org/cl/376361 mentions this issue: |
|
@findleyr I tried searching for the symbol (again highest score at the bottom) So this doesn't appear to be quite right to my mind at least? |
|
@myitcv could you try with |
|
For reference, here's what I get with the |
|
I should add: in my case the highest scoring results are at top! |
|
Ah thanks! That looks better. Just to observe however that a search criteria of (again, best match at bottom) That doesn't feel quite right to me? |
Err, embarrassingly I broke the tie the wrong way: I intended to do the opposite and prefer shorter. Patching, along with a proper test. Nice catch! |
|
Change https://golang.org/cl/377434 mentions this issue: |
|
Ok, the stack to improve this is mailed, although I don't go so far as to enable the fastfuzzy matcher by default. Since this is going to take some days to review and merge, and then some additional time to let the fastfuzzy matcher soak, this probably isn't going to make v0.7.5. Remilestoning for v0.8.0. As for why I only fixed this in the 'fastfuzzy' matcher: this matcher is knowledgeable about the structure of Go symbols, and so can do things like prefer matches further to the right of the fully qualified symbol string. This ends up being significantly more performant than trying to make a naive fuzzy matcher work for our purposes. The fastfuzzy matcher also just does a naive linear algorithm (not guaranteed to produce the highest score), which is sufficient for symbol matches, and is easier to maintain. |
|
Just tried https://go-review.googlesource.com/c/tools/+/377434/1; looks great to me! |
Add additional order invariants to workspace symbol results to differentiate between items of equal score: sort next by symbol length, and then finally by lexical ordering. For golang/go#50016 Change-Id: Ic5cda2628f57cecfe972b7585525c49b0f8518bf Reviewed-on: https://go-review.googlesource.com/c/tools/+/376360 Trust: Robert Findley <rfindley@google.com> Run-TryBot: Robert Findley <rfindley@google.com> gopls-CI: kokoro <noreply+kokoro@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Paul Jolly <paul@myitcv.org.uk>
In the new SymbolMatcher, add an additional scoring feature that considers whether the matching pattern streak is part of a whole-word match. This differentiates matches of "foo" against "pkg.foo" and "pkg.foobar". For golang/go#50016 Change-Id: Ib84ff13eee0b7ec23143325592cef9a41be07375 Reviewed-on: https://go-review.googlesource.com/c/tools/+/376361 Trust: Robert Findley <rfindley@google.com> Run-TryBot: Robert Findley <rfindley@google.com> Reviewed-by: Peter Weinberger <pjw@google.com> gopls-CI: kokoro <noreply+kokoro@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
Hook up the fastfuzzy symbol matcher to our fzf-style query parsing, for consistency with the (slow) fuzzy matcher. In the past I had wanted to implement this natively inside the SymbolMatcher, but it is much simpler to keep using combinators. In the common case we'll just be using fuzzy matching. For golang/go#50016 Change-Id: I1c62c8c8e9d29da570cb1e4034c2b10782529081 Reviewed-on: https://go-review.googlesource.com/c/tools/+/376362 Trust: Robert Findley <rfindley@google.com> Run-TryBot: Robert Findley <rfindley@google.com> gopls-CI: kokoro <noreply+kokoro@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Peter Weinberger <pjw@google.com>
The fastfuzzy matcher is around 3x faster than the fuzzy matcher for queries that need to search a large number of symbols, and has improved scoring due to built-in knowledge about the structure of Go symbols. Enable it in experimental builds of gopls, with plans to enable it by default in the next release. For golang/go#50016 Change-Id: Ie2c333f248bb8397d92f52fbbfdd2bf623372d0a Reviewed-on: https://go-review.googlesource.com/c/tools/+/377434 Trust: Robert Findley <rfindley@google.com> Run-TryBot: Robert Findley <rfindley@google.com> Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com> gopls-CI: kokoro <noreply+kokoro@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
|
Change https://golang.org/cl/382394 mentions this issue: |
Go version support
Support for Go 1.18
Version 0.8.0 of gopls supports features added to Go 1.18,
specifically:
Support for multi-module workspaces using go.work files.
Diagnostics for Fuzz tests. Improved support for generics.
To use these features, gopls must be installed using Go 1.18. See
go.dev/dl for the latest status of Go 1.18 -- as of writing Go 1.18
is not yet released, but Go 1.18 RC1 may be used.
Dropped support for Go 1.12
Version 0.8.0 of gopls no longer supports building at Go 1.12. See
golang/go#50827 for more details.
New Features
go.work integration
Gopls now supports multi-module workspaces using go.work files. To
use this feature, create a go.work file that includes the modules
you want to work on, and then open your editor to the directory
containing go.work. For more information, see the go.work reference,
or the gopls documentation for multi-module workspaces.
Diagnostics for Fuzz tests
When writing Fuzz tests, gopls provides diagnostics for invalid
arguments to Fuzz.
Improved support for generics
Honor the language version configured in go.mod
gopls now provides diagnostics for language features based on the
go directive in the applicable go.mod file for a package.
For some errors related to incompatible language versions, gopls
offers a quick-fix to update the go.mod Go version. (note that if
the go.mod file is open, it may need to be saved in order for
language version changes to take effect)
gomodedit
Improved completion with type parameters
Gopls autocompletion is improved in several contexts when using
generic types.
genericvarcompl
New code action to add missing method stubs
Gopls now provides a code action to implement missing methods.
Improved performance and accuracy for workspace symbol requests
Workspace symbols uses a new fuzzy matcher that is up to 3x faster
than previous, and has improved ranking. See golang/go#50016 for
more details. Note that the first time workspace symbols are
requested, there may be a delay as the symbol cache is populated.
Improved gofumpt integration
Gopls now sets the language version and module path when invoking
gofumpt, allowing more accurate formatting based on context.
What version of Go are you using (
go version)?Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (
go env)?go envOutputWhat did you do?
cue.ValueWhat did you expect to see?
Stable results, with
cuelang.org/go/cue.Valueas the result with the highest scoreWhat did you see instead?
Variously unstable results (highest score at the bottom,
fzf-UX):Logfile from a session in which I ran three such queries:
gopls.log
cc @findleyr
FYI @leitzler
The text was updated successfully, but these errors were encountered: