x/tools/gopls: symbol ranking algorithm edge case

[myitcv]

What version of Go are you using (go version)?

$ go version
go version go1.20.2 linux/arm64
$ go list -m golang.org/x/tools
golang.org/x/tools v0.9.2-0.20230511211205-01128f9fbc93
$ go list -m golang.org/x/tools/gopls
golang.org/x/tools/gopls v0.0.0-20230511211205-01128f9fbc93

Does this issue reproduce with the latest release?

Yes

What operating system and processor architecture are you using (go env)?

go env Output

$ go env
GO111MODULE=""
GOARCH="arm64"
GOBIN=""
GOCACHE="/home/myitcv/.cache/go-build"
GOENV="/home/myitcv/.config/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="arm64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/home/myitcv/gostuff/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/myitcv/gostuff"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/home/myitcv/gos"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/home/myitcv/gos/pkg/tool/linux_arm64"
GOVCS=""
GOVERSION="go1.20.2"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/home/myitcv/.vim/plugged/govim/go.mod"
GOWORK=""
CGO_CFLAGS="-O2 -g"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-O2 -g"
CGO_FFLAGS="-O2 -g"
CGO_LDFLAGS="-O2 -g"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -pthread -Wl,--no-gc-sections -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build2021304014=/tmp/go-build -gno-record-gcc-switches"

What did you do?

cd $(mktemp -d)
git init
git fetch https://review.gerrithub.io/cue-lang/cuelang.org refs/changes/96/553896/2
git checkout FETCH_HEAD

Then open your editor at the root of the repo and perform a symbol search for parseside

What did you expect to see?

The result:

github.com/cue-lang/cuelang.org/internal/cmd/preprocessor/cmd.parseContext.parse_sidebyside

to be returned as the best match.

What did you see instead?

The result:

github.com/cue-lang/cuelang.org/playground/internal/cuelang_org_go_internal/third_party/yaml.yaml_PARSE_FLOW_SEQUENCE_ENTRY_MAPPING_END_STATE

returned as the best match, with the desired best match second.

• gopls.log
• govim.log

[findleyr]

Thanks, eyeballing the match, I would have expected the desired result to be first. I'll debug.

[findleyr]

Sorry, we're trying to get the v0.12.0 release out, and this is something of an edge case, so it will have to wait for v0.13.0. Still a priority.

[myitcv]

Sorry, we're trying to get the v0.12.0 release out, and this is something of an edge case, so it will have to wait for v0.13.0. Still a priority.

No problems, appreciate you finding the time to update the issue!

[adonovan]

I can repro this using git clone https://github.com/cue-lang/cuelang.org.git and git checkout alpha. (The gerrit URL resulted in a password challenge.) I'm using the gopls defaults of "fast fuzzy matcher" and "dynamic symbolizer".

The cause appears to be the scoring algorithm implemented by (*fuzzy.SymbolMatcher).Match, which ranks yaml_[PARSE]_FLOW_[S]EQUENCE_ENTRY_MAPP[I]NG_EN[D]_STAT[E] very highly because it contains "parse" as a substring and the letters s, i, d, e in that order, following, as indicated by the square brackets. Paradoxically, the length of the identifier counts in its favor for scoring because of the "streak" logic, even though the connection with the search term is very tenous.

I'm out of my depth on how to fix it though. Assigning to @findleyr.

[myitcv]

I can repro this using git clone https://github.com/cue-lang/cuelang.org.git and git checkout alpha. (The gerrit URL resulted in a password challenge.)

Apologies, I didn't run the repro steps in a clean environment to catch that. Now updated to remove the authenticated GerritHub URL.

Paradoxically, the length of the identifier counts in its favor for scoring because of the "streak" logic, even though the connection with the search term is very tenous.

Thanks for investigating in any case!

[gopherbot]

Change https://go.dev/cl/531697 mentions this issue: internal/fuzzy: several improvements for symbol matching