你正在使用的Go版本是什么( go version
)?
$ go version
go version go1.21.1 linux/arm64
$ go list -m golang.org/x/tools
golang.org/x/tools v0.14.1-0.20231008020826-a3b5082fb05e
$ go list -m golang.org/x/tools/gopls
golang.org/x/tools/gopls v0.0.0-20231008020826-a3b5082fb05e
这个问题在最新版本中是否会重现?
是的
你正在使用什么操作系统和处理器架构( go env
)?
go env
输出
$ go env
GO111MODULE='on'
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=''
GOTOOLCHAIN='auto'
GOTOOLDIR='/home/myitcv/gos/pkg/tool/linux_arm64'
GOVCS=''
GOVERSION='go1.21.1'
GCCGO='gccgo'
AR='ar'
CC='gcc'
CXX='g++'
CGO_ENABLED='1'
GOMOD='/home/myitcv/gostuff/src/github.com/myitcv/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 -ffile-prefix-map=/tmp/go-build3782877243=/tmp/go-build -gno-record-gcc-switches'
你做了什么?
cd $(mktemp -d)
git clone https://github.com/cue-lang/cuelang.org
cd cuelang.org
git checkout 8c3444a51e940c9673af9f96b2f6cb0f98c32529 # alpha branch
打开vim/编辑器,并进行符号搜索 cue.Str
你期望看到什么?
作为最佳匹配结果的 cuelang.org/go/cue.Str
。
你看到了什么?
cuelang.org/go/cue.Str
作为第13个最佳匹配,其中一些更糟糕的匹配得分更高(按最高分优先)。
github.com/cue-lang/cuelang.org/internal/parse.ContinueNode.String
github.com/cue-lang/cuelang.org/playground/internal/cuelang_org_go_internal/third_party/yaml.yaml_document_t.start_mark
github.com/cue-lang/cuelang.org/playground/internal/cuelang_org_go_internal/third_party/yaml.yaml_document_t.start_implicit
github.com/cue-lang/cuelang.org/playground/internal/cuelang_org_go_internal/third_party/yaml.yaml_document_t.tag_directives_start
github.com/cue-lang/cuelang.org/playground/internal/cuelang_org_go_internal.ToStruct
github.com/cue-lang/cuelang.org/playground/internal/cuelang_org_go_internal.EmbedStruct
github.com/cue-lang/cuelang.org/playground/internal/cuelang_org_go_internal.Attr.String
github.com/cue-lang/cuelang.org/playground/internal/cuelang_org_go_internal.ConstraintToken
github.com/cue-lang/cuelang.org/playground/internal/cuelang_org_go_internal.SetConstraint
github.com/cue-lang/cuelang.org/playground/internal/cuelang_org_go_internal.scanAttributeElem
github.com/cue-lang/cuelang.org/playground/internal/cuelang_org_go_internal.scanAttributeString
github.com/cue-lang/cuelang.org/playground/internal/cuelang_org_go_internal/third_party/yaml.labelStr
cuelang.org/go/cue.Str
...
我本地会话的日志:
cc @findleyr
4条答案
按热度按时间2vuwiymt1#
谢谢。这肯定不对。评分算法很简单:(1)提示应该比继续得分更高,(2)较短的结果应该比较长的得分更高。
使用以下数据集进行复现:
gopls workspace_symbol -matcher=fastfuzzy "cue.str"
我会调查并修复v0.14.0版本。
qzlgjiam2#
这不是评分算法中的错误:
"cue.Str"
的模糊分数确实高于其他所有分数。但是"cue.Str"
的排名较低,因为它不在工作空间内——起初我并没有意识到这一点,因为它在一个提示包中,但在主要提示仓库中。以下具体步骤可以解决这个问题(但请参见下面的说明——这些步骤过于严格):
go work init && go work use -r .
这样,提示和cuelang.org都将被视为“在工作空间内”,结果将符合预期。但这对于没有强烈概念的“工作空间文件夹”的LSP客户端来说可能会令人困惑。我们通常将工作空间扩展到所有主要模块(包括go.work中指定的任何模块)。只需使用go.work文件,并从任何目录打开gopls就足够了。
似乎还有一种诱惑是删除非工作空间包的排名降低,但我们已经多次听到一些用户不希望看到任何非工作空间结果。我认为正确地尊重
go.work
文件在符号结果中的位置是解决这个问题的方法。sqyvllje3#
我认为正确地尊重符号结果中的
go.work
文件是解决这个问题的方法。我的意思是,你是建议我应该将
cuelang.org/go
依赖项添加到我的go.work
文件中,以便该依赖项的符号结果不会被降级吗?如果是这样的话,我认为在这种情况下或一般情况下这不是一个解决方案。因为
cuelang.org/go
只是许多依赖项中的一个,而且我不认为我会为此目的创建go.work
文件。如果这种降级是“糟糕”结果的原因(从我的Angular 来看),那么我相信 #37237 是更好的解决方案。因为采用这种方法,不需要这样的降级:我会明确处于搜索当前包、主模块、工作区等的模式。
5lwkijsr4#
请让我明确一下,你是建议我将cuelang.org/go依赖项添加到我的go.work文件中,以便符号结果不会被降级吗?
我没有建议采取任何行动 -我只是解释当前的排名以及背后的启发式方法。
A
go.work
是我们要求用户指定他们正在“工作”的代码的方式,而符号搜索会将结果降级到工作区之外。我认为当前的行为是错误的,因为用户还需要考虑“工作区文件夹”——我们尽可能地希望从配置空间中消除这个问题(参见#57979)。是的,#37237将解决那些整合了新语法或自定义命令的客户端的问题。