Documentation: Troubleshooting

[KBassford]

Please note somewhere that if the dependencies in your "go.mod" file do not match the current dependencies in your project, "gopls" will fail pretty catastrophically (ALL functionality listed on "https://code.visualstudio.com/docs/languages/go" is kaput). Renaming, deleting or regenerating this file restores all gopls functionality in the editor. This is a simple fix and should be noted somewhere to avoid unnecessary time lost, opening of issues, and emotional distress. (Us programmers are a high strung lot to begin with, don't need additional problems.)

[stamblerre]

You should not need to rename or delete your go.mod file to solve any problems with gopls, though running go mod tidy may be a good general tip for working with modules. Perhaps the documentation for this extension can reference the Modules wiki page, but this doesn't seem like an error specific to gopls. I would imagine that you would have encountered the same error when building your project.

gopls does not yet watch the user's go.mod file, although the work for this is currently in progress (you can follow along here: golang/go#31999). Once gopls does a better job of managing a user's go.mod file, we will be able to do a better job of surfacing these errors to users and clarifying the issue.

[KBassford]

Hi Ms. Stambler,
Ran "go mod tidy" before renaming go.mod to go.oldmod. It had no effect. Renaming the go.mod did restore all functionality. It was the gopls troubleshooting doc that prompted me try renaming the file. I have since regenerated the file and everything is still working properly.

I had previously revised my code to remove several dependencies, which seems to be when the problems started.

If you want to see ALL the gory details of what I went through to troubleshoot the problem, you can find them here: VSCodium/vscodium#289

[stamblerre]

I don't believe that we suggest renaming files in the gopls troubleshooting doc (are you referring to this one?). A go.mod file must be named that way to work, so likely what happened is that, when you renamed it, gopls began to function in GOPATH mode, which is why it appeared to be working again.

I agree that we should be able to show these errors and make them more plain to the user, and we will do this as part of the work on golang/go#31999. As it stands, we cannot recommend that users delete and recreate their go.mods when they encounter a gopls error. What you encountered was a genuine problem with your go.mod file, and ideally, gopls should guide you in how to fix it.

[KBassford]

I don't believe that we suggest renaming files in the gopls troubleshooting doc (are you referring to this one?).

This: https://github.com/golang/tools/blob/master/gopls/doc/user.md
And it was not mentioned explicitly. Seeing the flag "GO111MODULE" gave me the idea.

A go.mod file must be named that way to work, so likely what happened is that, when you renamed it, gopls began to function in GOPATH mode, which is why it appeared to be working again.

Exactly!

I agree that we should be able to show these errors and make them more plain to the user, and we will do this as part of the work on golang/go#31999. As it stands, we cannot recommend that users delete and recreate their go.mods when they encounter a gopls error. What you encountered was a genuine problem with your go.mod file, and ideally, gopls should guide you in how to fix it.

I look forward to that. Seeing that there are several similar issues to mine that inhabit the internet without apparent resolution (or at least with any listed), I believe a simple check that even the least technically inclined can preform would save a lot of time, money and hair pulling.

[stamblerre]

We are continuing to work on making errors more plain to the user as part of our work on gopls. golang/go#31668 is a similar issue that you can follow along with in the Go repository, but as there is no concrete action required by this issue, I will close it now.