x/tools/gopls: core functionality does not work in vendor directories

[EnigmaCurry]

What did you do?

I created a simple go program:

package main

import (
	"fmt"
)

func main() {
	fmt.
}

If I put the source code in the path ~/git/vendor/enigmacurry/go-play/hello.go, using gopls to complete on line 8 directly after fmt. it does not yield valid candidates for completion of fmt. Instead, it gives me these completions:

However, if I put the same source code in a different directory, ~/git/go-play/hello.go, completion is working correctly:

I have created two gopls debug logs:

• This is the debug log for the broken session of ~/git/vendor/enigmacurry/go-play/hello.go (see lines 309-314)
• This is the debug log for the working session of ~/git/go-play/hello.go (see lines 211-216)

I have tested in a total of three environments:

• Emacs 28 lsp-mode (config here)
• Emacs 28 eglot mode
• VS Code (vscodium 1.68.1 with golang/vscode-go extension v0.34.1 and default settings)

All environments showed the same result. I have replicated the problem on two separate machines (Arch Linux and Manjaro).

What did you expect to see?

I expected to see valid completions of fmt in both files in both sessions in both directories.

What did you see instead?

The source in ~/git/vendor/enigmacurry/go-play/hello.go does not offer valid completions.

The parent directory ~/git/vendor hosts many other repositories totaling 18GB, which may be a factor as this bug appears to be directory specific.

Build info

gopls is installed directly from the Arch Linux repository:

$ pacman -Qo gopls
/usr/bin/gopls is owned by gopls 0.8.4-1

golang.org/x/tools/gopls v0.8.4
    golang.org/x/tools/gopls@(devel)
    github.com/BurntSushi/toml@v1.0.0 h1:dtDWrepsVPfW9H/4y7dDgFc2MBUSeJhlaDtK13CxFlU=
    github.com/google/go-cmp@v0.5.7 h1:81/ik6ipDQS2aGcBfIN5dHDB36BwrStyeAQquSYCV4o=
    github.com/sergi/go-diff@v1.1.0 h1:we8PVUC3FE2uYfodKH/nBHMSetSfHDR6scGdBi+erh0=
    golang.org/x/exp/typeparams@v0.0.0-20220218215828-6cf2b201936e h1:qyrTQ++p1afMkO4DPEeLGq/3oTsdlvdH4vqZUBWzUKM=
    golang.org/x/mod@v0.6.0-dev.0.20220419223038-86c51ed26bb4 h1:6zppjxzCulZykYSLyVDYbneBfbaBIQPYMevg0bEwv2s=
    golang.org/x/sync@v0.0.0-20210220032951-036812b2e83c h1:5KslGYwFpkhGh+Q16bwMP3cOontH8FOep7tGV86Y7SQ=
    golang.org/x/sys@v0.0.0-20220209214540-3681064d5158 h1:rm+CHSpPEEW2IsXUib1ThaHIjuBVZjxNgSKmBLFfD4c=
    golang.org/x/text@v0.3.7 h1:olpwvP2KacW1ZWvsR7uQhoyTYvKAupfQrRGBFM352Gk=
    golang.org/x/tools@v0.1.11-0.20220513164230-dfee1649af67 h1:CJwk4qG1fov4WP7/DWhhb7OQVZlQKAl1rEMnDF+ceGU=
    golang.org/x/vuln@v0.0.0-20220503210553-a5481fb0c8be h1:jokAF1mfylAi1iTQx7C44B7vyXUcSEMw8eDv0PzNu8s=
    honnef.co/go/tools@v0.3.0 h1:2LdYUZ7CIxnYgskbUZfY7FPggmqnh6shBqfWa8Tn3XU=
    mvdan.cc/gofumpt@v0.3.0 h1:kTojdZo9AcEYbQYhGuLf/zszYthRdhDNDUi2JKTxas4=
    mvdan.cc/xurls/v2@v2.4.0 h1:tzxjVAj+wSBmDcF6zBB7/myTy3gX9xvi8Tyr28AuQgc=
go: go1.18.2

[EnigmaCurry]

If I rename ~/git/vendor to ~/git/vendor2 it works.

[findleyr]

Just looked into this.

I don't think this ever worked. Or at least I reproduced it and tried to bisect all the way back to gopls/v0.7.0 (approximately as far back as one can go without running into build problems), and it seems to have always been a problem.

We should and will still fix, though perhaps with less urgency than if this were a recent regression.

[gopherbot]

Change https://go.dev/cl/419111 mentions this issue: internal/lsp/cache: check for /vendor/ relative to workspace root

[findleyr]

Have to move on for now, but https://go.dev/cl/419111 contains a sketch of a solution: when checking if a file is "vendored" (generally used to detect that we don't care about it), consider paths relative to workspace root. This makes the included regression test pass, and might be sufficient, but it requires some analysis (and we'll see if other tests pass).

It seems quite possible that this CL is insufficent though. Perhaps we want to consider paths relative to module root, not workspace root.