x/tools/gopls: loading workspace hangs on v0.8.1, works on v0.8.0

[geitir]

gopls version

golang.org/x/tools/gopls v0.8.1

go env

go1.18

What did you do? What did you expect to see? What did you see instead?

gopls hangs on "loading workspace loading packages" with high cpu usage indefinitely on opening project

Editor and settings

VSCode

Logs

[seankhliao]

please fill out the issue template properly, there are instructions on commands to run to capture important debugging information.

[geitir]

Hi. I closed hoping this would resolve in the next few releases but v0.8.3 still has the same issue.

I work in a large monorepo (this could very well be an issue with our configuration) and was hesitant to report debugging info but I will report back

[geitir]

gopls -v version

golang.org/x/tools/gopls v0.8.3
    golang.org/x/tools/gopls@v0.8.3 h1:Mxm94ix8oSARQ6svioO6SxKEYWT/VCP54/448LOHzrk=
    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.20220106191415-9b9b3d81d5e3 h1:kQgndtyPBW/JIYERgdxfwMYh3AVStj88WQTlNDi2a+o=
    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.20220407163324-91bcfb1bdf9c h1:rYiuK/jn6TCxjAq1hQ6MR6pgOeP3A5gIHDxgrQ8Vbys=
    golang.org/x/vuln@v0.0.0-20220324005316-18fd808f5c7f h1:9dMzk88fnONra7zrEalqkRMGa9jMGf9B5mdzhYVyI28=
    golang.org/x/xerrors@v0.0.0-20200804184101-5ec99f83aff1 h1:go1bK/D/BFZV2I8cIQd1NKEZ+0owSTG1fDTci4IqFcE=
    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

go env

USER@USER-XXX % go env
GO111MODULE="off"
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/USER/Library/Caches/go-build"
GOENV="/Users/USER/Library/Application Support/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOINSECURE=""
GOMODCACHE="/Users/USER/REPONAME/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="darwin"
GOPATH="/Users/USER/REPONAME"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/private/var/tmp/_bazel_USER/39f85239c7a58bb315210c358a75a4cd/external/go_sdk"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/private/var/tmp/_bazel_USER/39f85239c7a58bb315210c358a75a4cd/external/go_sdk/pkg/tool/darwin_amd64"
GOVCS=""
GOVERSION="go1.18"
GCCGO="gccgo"
GOAMD64="v1"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD=""
GOWORK=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -arch x86_64 -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/1v/19_n0_c57fgbpbd2rzzf4zt80000gn/T/go-build1587897350=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

• open monorepo in vscode
• vscode hangs on "Setting up workspace: Loading packages..." with go and gopls processes continually running

vscode settings.json

{
    "files.watcherExclude": {
        "bazel-*": true,
        "pkg*": true,
    },
    "files.exclude": {
        "bazel-*": true,
        "pkg*": true,
    },
    "go.inferGopath": false,
    "go.gopath": "/${env:HOME}/REPONAME",
    "go.goroot": "~/REPONAME/bazel-REPONAME/external/go_sdk",
    "go.toolsEnvVars": {
        "GO111MODULE": "off"
    },
    "go.buildOnSave": "workspace",
    "go.vetOnSave": "workspace",
    "go.buildFlags": [],
    "go.lintFlags": [],
    "go.vetFlags": [],
    "go.coverOnSave": false,
    "go.useCodeSnippetsOnFunctionSuggest": false,
    "go.formatTool": "goimports",
    "go.autocompleteUnimportedPackages": true,
    "go.useLanguageServer": true,
    "go.languageServerFlags": [
        "-logfile", "/tmp/gopls.log",
        "-rpc.trace"
    ],
    "launch": {
        "version": "0.2.0",
        "configurations": [
        {  
            "name": "Go: Connect to server",
            "type": "go",
            "request": "attach",
            "debugAdapter": "dlv-dap",
            "mode": "remote",
            "port": 2345,
            "host": "127.0.0.1",
            "trace": "info",
            "substitutePath": [
                {
                    "from": "${workspaceFolder}/src",
                    "to": "src"
                },
                {
                    "from": "${workspaceFolder}/bazel-REPONAME/external/",            
                    "to": "external/"
                },
                {
                     "from": "${workspaceFolder}/bazel-out/",
                     "to": "bazel-out/"
                },
                {
                    "from": "${workspaceFolder}/bazel-REPONAME/external/go_sdk",
                    "to": "GOROOT/"
                }
            ]
        }
        ]
    }
}

[findleyr]

Hi, sorry we missed this after it was reopened.

Looking at the commits between gopls@v0.8.0 and gopls@v0.8.1, I'd love to know which caused the regression you observed; there are not a lot of likely candidates.

Would you be willing to bisect this problem? If so, it seems likely that we could fix it.

A few follow-up questions:

1. Can you try building gopls@v0.8.3 with go 1.17? (you can use https://pkg.go.dev/golang.org/dl and then go1.17.10 install golang.org/x/tools/gopls@v0.8.3?
2. Are you using bazel?
3. Are you using go.work files?
4. Approximately how many files do you have in your workspace?

Thanks!