Repository: go
Issue: x/tools/gopls: core functionality does not work in vendor directories
Labels: NeedsInvestigation,gopls,Tools,gopls/workspace

#### 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:

![image](https://user-images.githubusercontent.com/43061/178033253-55f6c956-23c8-497e-8f84-b1a57358d78b.png)

However, if I put the same source code in a different directory, `~/git/go-play/hello.go`, completion is working correctly:

![image](https://user-images.githubusercontent.com/43061/178033567-2e7025f5-2be3-4424-a261-63b7b33ebd7f.png)

I have created two gopls debug logs:

 * [This is the debug log for the **broken** session of  `~/git/vendor/enigmacurry/go-play/hello.go`](https://gist.github.com/EnigmaCurry/5d990c6996a937df709cda13d2799087) (see lines 309-314)
 * [This is the debug log for the **working** session of  `~/git/go-play/hello.go`](https://gist.github.com/EnigmaCurry/db841702eb997a2d211f45d11ab7f69c) (see lines 211-216)

I have tested in a total of three environments:
 * Emacs 28 lsp-mode ([config here](https://github.com/EnigmaCurry/emacs/blob/8a08c5471ff3a6365f206e792e9003e0323b8815/init.el#L327-L338))
 * 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
```