x/tools/gopls: `lo` package is not autocompleted if it's not already imported

[vikstrous2]

lo refers to https://github.com/samber/lo
I'm using gopls in vs code

gopls version

gopls -v version
Build info
----------
golang.org/x/tools/gopls v0.12.3
    golang.org/x/tools/gopls@v0.12.3 h1:u0wCI9uvt7mnmri6bFBIaWw1XCN6PN8hKv55Zwd+GbE=
    github.com/BurntSushi/toml@v1.2.1 h1:9F2/+DoOYIOksmaJFPw1tGFy1eDnIJXg+UHjuD8lTak=
    github.com/google/go-cmp@v0.5.9 h1:O2Tfq5qg4qc4AmwVlvv0oLiVAGB7enBSJ2x2DqQFi38=
    github.com/sergi/go-diff@v1.1.0 h1:we8PVUC3FE2uYfodKH/nBHMSetSfHDR6scGdBi+erh0=
    golang.org/x/exp@v0.0.0-20220722155223-a9213eeb770e h1:+WEEuIdZHnUeJJmEUjyYC2gfUMj69yZXw17EnHg/otA=
    golang.org/x/exp/typeparams@v0.0.0-20221212164502-fae10dda9338 h1:2O2DON6y3XMJiQRAS1UWU+54aec2uopH3x7MAiqGW6Y=
    golang.org/x/mod@v0.11.0 h1:bUO06HqtnRcc/7l71XBe4WcqTZ+3AH1J59zWDDwLKgU=
    golang.org/x/sync@v0.3.0 h1:ftCYgMx6zT/asHUrPw8BLLscYtGznsLAnjq5RH9P66E=
    golang.org/x/sys@v0.9.0 h1:KS/R3tvhPqvJvwcKfnBHJwwthS11LRhmM5D59eEXa0s=
    golang.org/x/text@v0.10.0 h1:UpjohKhiEgNc0CSauXmwYftY1+LlaC75SJwh0SgCX58=
    golang.org/x/tools@v0.10.1-0.20230621152627-79dae4d1afc7 h1:OqO0SKgRQpzXVmbHUZc/ropwr82dwTQPJtJ9HHNMy2c=
    golang.org/x/vuln@v0.0.0-20230110180137-6ad3e3d07815 h1:A9kONVi4+AnuOr1dopsibH6hLi1Huy54cbeJxnq4vmU=
    honnef.co/go/tools@v0.4.2 h1:6qXr+R5w+ktL5UkwEbPp+fEvfyoMPche6GkOpGHZcLc=
    mvdan.cc/gofumpt@v0.4.0 h1:JVf4NN1mIpHogBj7ABpgOyZc65/UUOkKQFkoURsz4MM=
    mvdan.cc/xurls/v2@v2.4.0 h1:tzxjVAj+wSBmDcF6zBB7/myTy3gX9xvi8Tyr28AuQgc=
go: go1.20.4

go env

Probably not relevant.

What did you do?

Any time I want to use lo, I type lo. or lo<tab> and it never gets auto-imported. I have to resort to typing lo.Map and saving the file to trigger the auto-import.

To repro just create this go.mod file:

module example.com

go 1.20

require (
	github.com/samber/lo v1.38.1 // indirect
	golang.org/x/exp v0.0.0-20220303212507-bbda1eaf7a17 // indirect
)

and try auto-completing lo in a main.go file.

After importing it successfully once, it seems to eventually start to pop up in suggestions.. but even then it's never first.

It really hurts the usability of this package when you can't get auto-completion without importing it first. I'm pretty sure there's something special about the length of the package name that's causing this because I haven't seen this problem with other packages.

What did you expect to see?

What did you see instead?

Editor and settings

nothing very relevant in settings.json

  "go.testFlags": ["-v"],
  "go.testEnvVars": { "GODEBUG": "tracebackancestors=5" },
  "gopls": {
    "formatting.gofumpt": true,
  },

Logs

Sorry, I haven't dig into it deeper yet and set up extra logging.

[findleyr]

This is another issue with unimported completion.

Thanks for the repro, we'll take a look.

[adonovan]

I can reproduce this on master, running it in the gopls workspace with an empty local package called lo. It happens that there are 6 unimported packages that are candidates for completion of lo, and the internal threshold constant maxUnimportedPackageNames is 5, so lo just doesn't make the cut. If I instead use an obscure package name like xq, it works fine: the very first time, there's a slight delay, during which xq<TAB> causes completion to crypto/x509, but after that xq is always the first completion.

When I try again using github.com/samber/lo, I get similar behavior except that its relevance score (4) is lower than that of the local package (6)---even when it is already imported in that file. "log" always has a higher relevance.

In short, this is a ranking problem, and perhaps just an unfortunate confluence of a short cutoff (5), a short name (2), and the presence of a much more popular package (log). We could increase the cutoff, but I suspect the problem would then appear with a different specific package.

[vikstrous2]

Ah, very unlucky package name... Is there some way to ensure that exact matches are always found? Some exception that can be made to the unimported package search logic?

[adonovan]

Now that we know the cause, I'm going to close this issue as a dup of #60988.