x/tools/gopls: don't load invalid build configurations unless they contain Go code

[andypwarren]

Gopls is running very slowly in vscode when inside a workspace

What did you do?

Opened up a vscode workspace, waited for Go extension to initialise and started typing.

What did you expect to see?

code completion results opening quickly

What did you see instead?

The red squiggly line moves very slowly across the word and the code completion results come up after a few seconds

Build info

golang.org/x/tools/gopls v0.5.5
    golang.org/x/tools/gopls@v0.5.5 h1:YBLs2WCwxx6mBF98Y6/mDIpKhP4Dt4Dz2q6LnMRBpDw=
    github.com/BurntSushi/toml@v0.3.1 h1:WXkYYl6Yr3qBf1K79EBnL4mak0OimBfB0XUf9Vl28OQ=
    github.com/google/go-cmp@v0.5.1 h1:JFrFEBb2xKufg6XkJsJr+WbKb4FQlURi5RUcBveYu9k=
    github.com/sergi/go-diff@v1.1.0 h1:we8PVUC3FE2uYfodKH/nBHMSetSfHDR6scGdBi+erh0=
    golang.org/x/mod@v0.3.0 h1:RM4zey1++hCTbCVQfnWeKs9/IEsaBLA8vTkd0WVtmH4=
    golang.org/x/sync@v0.0.0-20201020160332-67f06af15bc9 h1:SQFwaSi55rU7vdNs9Yr0Z324VNlrF+0wMqRXT4St8ck=
    golang.org/x/tools@v0.0.0-20201204180437-c46b611624b3 h1:uxH+MECLNmX/vsPe4txyeQ1LCmhdUxf7p4hjkHexg+c=
    golang.org/x/xerrors@v0.0.0-20200804184101-5ec99f83aff1 h1:go1bK/D/BFZV2I8cIQd1NKEZ+0owSTG1fDTci4IqFcE=
    honnef.co/go/tools@v0.0.1-2020.1.6 h1:W18jzjh8mfPez+AwGLxmOImucz/IFjpNlrKVnaj2YVc=
    mvdan.cc/gofumpt@v0.0.0-20200927160801-5bfeb2e70dd6 h1:z+/YqapuV7VZPvBb3GYmuEJbA88M3PFUxaHilHYVCpQ=
    mvdan.cc/xurls/v2@v2.2.0 h1:NSZPykBXJFCetGZykLAxaL6SIpvbVy/UFEniIfHAa8A=

[stamblerre]

Can you please share your gopls logs? Information on how to capture them can be found here.

[andypwarren]

This is the log result when I type errors into a Go file. The file has around 500 lines of Go code and the workspace has 11 directories, 5 of which are Go projects, using modules.
gopls-logs.log

[stamblerre]

It looks like gopls cannot find the go.mod files for these different directories--where are the go.mod files located and how is your workspace set up? Also, if possible, can you please make sure your log starts from the very beginning (the initialize request) because that includes more relevant debug information. Thanks!

[andypwarren]

Hi @stamblerre Thanks for taking the time to investigate this. All the go.mod files are located in the root of their respective directories e.g.

├── contentsvc
│   ├── go.mod
├── graphql
│   ├── go.mod

The workspace was setup awhile ago using the Add folder to workspace action. I've been using previous releases of gopls for a while without this issue.
gopls-log-init.log

[stamblerre]

It looks like gopls is struggling with the following directories:

/Users/andy/p1/charts
/Users/andy/p1/configs
/Users/andy/p1/admin
/Users/andy/p1/frontend
/Users/andy/p1/terraform

Are these modules / do they contain Go code?

[andypwarren]

No those directories don't contain any Go code.

[stamblerre]

It looks like gopls is finding packages in those directories. Can you try running go list -e -json -compiled ./ in /Users/andy/p1/charts or any of those other directories?

[andypwarren]

That command returns "Err": "no Go files in /Users/andy/p1/charts" and is the same for all the other none Go directories.

Heres the full output

{
	"Dir": "/Users/andy/p1/charts",
	"ImportPath": "_/Users/andy/p1/charts",
	"Match": [
		"./charts"
	],
	"Incomplete": true,
	"Error": {
		"ImportStack": [
			"./charts"
		],
		"Pos": "",
		"Err": "no Go files in /Users/andy/p1/charts"
	}
}

[gopherbot]

Change https://golang.org/cl/277114 mentions this issue: internal/lsp/cache: filter packages before logging their count

[stamblerre]

After some further investigation, it looks like we aren't actually processing these packages with no Go files. However, it may aid in investigation if you can try setting GO111MODULE=on explicitly in your environment. Does that change the outcome at all?

[andypwarren]

Unfortunately the issue remained after setting GO111MODULE. However, I've upgraded to version 0.6.0 and the issue seems to have been resolved. It's much more performant now using the same workspace.

[stamblerre]

Glad to hear that the issue is resolved. I'll go ahead and close this then.