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.

This error message comes straight from the go command, and I don't think go mod tidy is always the right solution. But Bryan and Jay should speak to that.

As for continuing, unfortunately gopls needs information from the go command to provide editor services and in this situation it simply can't get it. Turning off vendor mode might fix the problem, but I don't think gopls should be doing that of its own volition. It might result in downloading stuff, or it might make things worse.

@bcmills @jayconrod

Indeed, go mod tidy can delete requirements, and we shouldn't necessarily recommend running it.

Just to confirm, go mod vendor alone did not resolve the error, but go mod tidy followed by go mod vendor did? What changes did go mod tidy make to go.mod?

If go mod vendor succeeded, it seems like a bug if there's an "inconsistent vendoring" error afterward. Either go mod vendor should fail, or it should ensure go.mod and vendor/modules.txt are consistent.

As for continuing, unfortunately gopls needs information from the go command to provide editor services and in this situation it simply can't get it.

I think it's desirable for e.g. code completion to be forgiving and "fuzzy" rather than unforgiving and strict — I'd rather have some code completion than none even if my code base is partially "broken".

If the introduction of this new check in the go tool introduced in 1.14 is not possible to bypass by the downstream tooling, I think the second best would be to at least show this error to the user. Right now vscode-go is completely quiet unless you dive into the gopls debug output. But maybe that's an issue that should be opened in vscode-go.

Just to confirm, go mod vendor alone did not resolve the error, but go mod tidy followed by go mod vendor did? What changes did go mod tidy make to go.mod?

Yes. go mod vendor added an // indirect comment to the module in question in go.mod, but didn't remove the ## explicit annotation in vendor/modules.txt; the tooling continued to give the same error. After I ran go mod tidy, and then go mod vendor, the module in go.mod was removed and the ## explicit annotation was removed, and then the tooling was happy. For more clarity:

before

something.go:
import (
   "github.com/my-co/whatever"
)

go.mod:
require (
    github.com/my-co/whatever v0.0.0-xxxxx-abcd
)

vendor/module.txt:
# github.com/my-co/whatever v0.0.0-xxxxx-abcd
## explicit
github.com/my-co/whatever

After update that borked gopls:

something.go:
import (
   "github.com/my-co/something-else-that-transitively-includes-whatever"
)

go.mod (same):
require (
    github.com/my-co/whatever v0.0.0-xxxxx-abcd
)

vendor/module.txt (same):
# github.com/my-co/whatever v0.0.0-xxxxx-abcd
## explicit
github.com/my-co/whatever

After go mod vendor (same error from tooling)

something.go:
import (
   "github.com/my-co/something-else-that-transitively-includes-whatever"
)

go.mod (now has "// indirect"):
require (
    github.com/my-co/whatever v0.0.0-xxxxx-abcd // indirect
)

vendor/module.txt (same):
# github.com/my-co/whatever v0.0.0-xxxxx-abcd
## explicit
github.com/my-co/whatever

After go mod tidy && go mod vendor:

something.go:
import (
   "github.com/my-co/something-else-that-transitively-includes-whatever"
)

go.mod:
require (
   <no longer includes whatever>
)

vendor/module.txt (no more ## explicit):
# github.com/my-co/whatever v0.0.0-xxxxx-abcd
github.com/my-co/whatever

The token ##explicit in your pasted examples is suspect. The actual token that the modules.txt parser looks for has a space after the ##:

Could you publish a repo that shows the actual contents of the files at the named phases? I wonder if something in gopls or the editor hooks is ending up corrupting the tokens, or perhaps gopls is internally using a go.mod that differs from the one in your source tree.

I re-typed that by hand while looking at my git history; the actual file did, in fact, have the space. This is proprietary code so I can't publish the repo, I hope that there's enough information above.

(I edited my example to be more correct)

The change from direct to // indirect after go mod vendor, especially combined with the proprietary code, makes me wonder whether this is the same underlying problem as #38846.

@evanmoses-okta, can you confirm whether your setup may be importing packages symlinked into the main module's source tree, and/or importing packages with normally-ignored components (such as testdata or _foo)?

Not as far as I know. I was able to reproduce the behavior of the tooling (that is, adding // indirect after go mod vendor) in this trivial repo, although I didn't get errors from gopls: https://github.com/evanmoses-okta/gopls-error-repro

In that repo, I

1. Created moda and consumer that depends on it, and ran go mod vendor
2. Created modb which depends on moda
3. Changed consumer to depend on modb instead of moda
4. This caused go build to complain about inconsistent vendoring
5. Ran go mod vendor, which added the // indirect comment in go.mod while leaving the ## explicit in vendor/modules.txt alone, as in this issue. This did not appear to break tooling, although obviously this is a much simpler repo and maybe there are further confounding factors.

Running go mod tidy in this repo will remove moda from consumer's go.mod and remove the ## explicit annotation in modules.txt

Change https://golang.org/cl/235619 mentions this issue: internal/lsp: support go mod vendor as a command

I don't think there's anything to do here after CL 235619, apart for waiting for #39164 to be resolved in 1.16.