x/tools/gopls: complains about inconsistent vendoring in the standard library

[FiloSottile]

To reproduce, simply open the $GOROOT/src directory of current master.

• vscode-go version: 2020.7.820
• gopls version: golang.org/x/tools/[email protected] h1:SPpw/YOMhYKB5TjtZj77ddcTDQkpkUZtw4+0jtVYwro=
• go version: devel +6ba3e6a8c7

My config

    "go.gopath": "~",
    "go.toolsGopath": "~/.vscode/gopath",
    "go.autocompleteUnimportedPackages": true, // https://golang.org/issue/31906
    "go.useLanguageServer": true,
    "go.enableCodeLens": {
        "runtest": false,
        "references": false
    },
    "[go]": {
        "editor.snippetSuggestions": "none",
        "editor.codeActionsOnSave": {
            "source.organizeImports": true
        },
    },
    "gopls": { // https://github.com/golang/tools/blob/master/gopls/doc/settings.md
        "staticcheck": true,
        "hoverKind": "FullDocumentation",
        "deepCompletion": true,
        "completeUnimported": true, // https://golang.org/issue/31906
    },

My workspace config

{
    "go.alternateTools": {
        "go": "~/go/bin/go"
    },
    "go.toolsGopath": "~/.vscode/godev",
    "html.format.enable": false,
    "editor.codeActionsOnSave": {
        "source.organizeImports": false
    },
    "gopls": {
        "analyses": {
            "ST1003": false,
        },
    },
    "go.languageServerFlags": [
        "-rpc.trace"
    ],
}

[stamblerre]

I'm not able to reproduce this. Can you share the gopls logs? (https://github.com/golang/tools/blob/master/gopls/doc/troubleshooting.md#capturing-logs) Does running go mod vendor fix the issue?

[FiloSottile]

It's been happening on and off for a few days and I am not seeing it right now. (Maybe since I rebuilt the go binary? I do that a lot.) I'll collect logs when it happens again.

go mod vendor does not make any change. (There are TryBots to check that the stdlib is always clean.)

[stamblerre]

Hm, you're right that it probably has something to do with the go binary. Let me know if you catch it again.

[josharian]

This has been happening to me as well; it's not just @FiloSottile. I haven't dug into why, but I'd love for it to be fixed. :)

[stamblerre]

/cc @heschik for vendoring, @jayconrod for go command - all gopls does is run go list -e -json -compiled ./src/... in the standard library. I don't know enough about vendoring to understand how this would happen, unless the go.mod file was changing.

[jayconrod]

The go command reports this error when go.mod is inconsistent with vendor/modules.txt. If neither file has changed since the last go mod vendor run, this error shouldn't be reported.

Could there be some mismatch between the go binary being used, the GOROOT directory, and the GOROOT environment (if set explicitly)?

[stamblerre]

I just checked, and I can't reproduce this with Go 1.14 or when my go binary matches the stdlib.
So, @FiloSottile and @josharian, the next step would be to grab your gopls logs when this happens, and then to run go list -e -json -compiled -test ./src/... to see if it's reproducible.

[gopherbot]

Timed out in state WaitingForInfo. Closing.

(I am just a bot, though. Please speak up if this is a mistake or you have the requested information.)