x/tools/gopls: errors in go.mod file prevents initial workspace load

[ridersofrohan]

What version of Go are you using (go version)?

$ go version
go version devel +8ac98e7b3f Thu Jan 9 18:00:06 2020 +0000 darwin/amd64

Does this issue reproduce with the latest release?

Yes

What did you do?

-- go.mod --
module mod.com

require golang.org/x/tools v0.0.0-20200107184032-11e9d9cc0042

yo

-- main.go --
package main

import "golang.org/x/tools/go/packages"

func Yo() {
	var _ packages.Config
}

What did you expect to see?

I expected the go.mod error to surface with the initial workspace load.

What did you see instead?

I saw that gopls logged the error due to the initial call packages.load call when the view is created. However, since there was an error with that initial load all the LSP features break. The error shows up once you save a .go file or start making edits in the go.mod file.

/cc @stamblerre

[gopherbot]

Thank you for filing a gopls issue! Please take a look at the Troubleshooting guide, and make sure that you have provided all of the relevant information here.

[ridersofrohan]

There is another place where the error message should be checked if it is related to a go.mod parse error: internal/lsp/cache/load.go#L72. Adding the same check as on internal/lsp/cache/builtin.go#L40 here would cause the go.mod error to show up on initial load of the workspace.

However, even after the error is addressed and the go.mod file is saved, gopls does not seem to call packages.load again and the error diagnostic does not disappear from the go.mod file.

[stamblerre]

As a follow-up to https://golang.org/cl/214417, I will look into making one go/packages.Load call for "builtin" and the workspace. This should at least reduce the amount of special-cases needed. We do still have to figure out (1) what gopls should do when it sees an invalid go.mod file on start, and (2) if gopls should try to re-initialize if initialization failed.

[gopherbot]

Change https://golang.org/cl/214877 mentions this issue: internal/lsp/cache: refactor initialization for builtins

[stamblerre]

Now that the above CL has been merged, the main question remains: How should gopls behave when your go.mod is broken. Realistically, we can't do anything until the initial workspace load succeeds, but we have to recover gracefully.

The problem is that we don't want to keep trying to initialize if it keeps failing. I propose that, if we have an initialization error, we retry after every change to the go.mod.

[ridersofrohan]

Yeah, I think that approach works, since we will be able to surface go.mod errors even when the initial workspace load breaks.