can't install golang.org/x/tools/gopls@latest

[shivatejesh]

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

$ go version
go version go1.12.6 darwin/amd64

Does this issue reproduce with the latest release?

Yes. (I need clarity on the question, latest release of what?)

What operating system and processor architecture are you using (go env)?

go env Output

$ go env
Setting GO111MODULE to on
Using go version go1.12.6 darwin/amd64...
Running command "go env"...
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/shivatejeshrachamadugu/Library/Caches/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/shivatejeshrachamadugu/go-code"
GOPROXY=""
GORACE=""
GOROOT="/private/var/tmp/_bazel_shivatejeshrachamadugu/2c13d2577b0574449ad6dc3a0a75269b/external/go_sdk"
GOTMPDIR=""
GOTOOLDIR="/private/var/tmp/_bazel_shivatejeshrachamadugu/2c13d2577b0574449ad6dc3a0a75269b/external/go_sdk/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/Users/shivatejeshrachamadugu/go-code/go.mod"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/jj/k1xw77pd6knd3tyw2qgpwdjh0000gn/T/go-build648584742=/tmp/go-build -gno-record-gcc-switches -fno-common"
Skipping gazelle run due to no changes to go.mod or go.sum

What did you do?

go get golang.org/x/tools/gopls@latest

What did you expect to see?

Get gopls installed

What did you see instead?

shivatejeshrachamadugu-C02X74ABJGH6:go-code shivatejeshrachamadugu$ go get golang.org/x/tools/gopls@latest
Setting GO111MODULE to on
Using go version go1.12.6 darwin/amd64...
Running command "go get golang.org/x/tools/gopls@latest"...
golang.org/x/tools/gopls
../../pkg/mod/golang.org/x/tools/gopls@v0.1.3/main.go:20:41: not enough arguments in call to cmd.New
have (string, nil)
want (string, string, []string)

I have followed the steps over here #33464, but didn't succeed.

[gopherbot]

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

[bcmills]

Oh, dear. gopls/main.go is importing an internal package from another module.

That's only ok if the internal package has a stable API: otherwise, a user's go.mod file might upgrade the internal package to a version newer than what gopls expects, as seems to have happened here.

@shivatejesh, as a workaround you can either downgrade the golang.org/x/tools module to v0.0.0-20190710153321-831012c29e42, or you can upgrade golang.org/x/tools/gopls to commit 625c92e46d0e or newer.

CC @ianthehat @hyangah @stamblerre

[ianthehat]

We don't support building gopls with any version of x/tools (or any other module we depend on) other than the versions we specify in the go.mod

On the install instructions we say

If you do want to get the latest stable version of gopls, change to any directory that is not in either your GOPATH or a module (a temp directory is fine), and use
go get golang.org/x/tools/gopls@latest

specifically to avoid triggering this case.

[shivatejesh]

I did followed your instructions and changed go.mod file got changed like this

	golang.org/x/tools v0.0.0-20190710153321-831012c29e42
	golang.org/x/tools/gopls v0.1.3 // indirect

and in terminal when I get gopls version, this is what I get.

shivatejeshrachamadugu-C02X74ABJGH6:go-code shivatejeshrachamadugu$ gopls version
golang.org/x/tools/gopls v0.1.2
    golang.org/x/tools/gopls@v0.1.3 h1:CB5ECiPysqZrwxcyRjN+exyZpY0gODTZvNiqQi3lpeo=

I do not understand why 0.1.2 is being installed. And no autocomplete and no other features are working in visual studio code. Set of instructions that appear for a function are these in visual code.

And the settings.json in visual code are

settings.json Output

$ settings.json
{
    "go.gopath": "/Users/shivatejeshrachamadugu/go-code",
    "go.coverOnSingleTest": true,
    "debug.showSubSessionsInToolBar": true,
    "go.languageServerExperimentalFeatures": {
        "diagnostics": true, // for diagnostics as you type
        "format": true,
        "autoComplete": true,
        "rename": true,
        "goToDefinition": true,
        "hover": true,
        "signatureHelp": true,
        "goToTypeDefinition": true,
        "goToImplementation": true,
        "documentSymbols": true,
        "workspaceSymbols": true,
        "findReferences": true,
        "documentLink": true,
        "incrementalSync": true,
    },
    "go.toolsEnvVars": {
        "GO111MODULE": "on"
    },
    "gopls": {
        "usePlaceholders": true,
        "enhancedHover": true,
    },
    "[go]": {
        "editor.snippetSuggestions": "none",
        "editor.formatOnSave": false,
        "editor.codeActionsOnSave": {
            "source.organizeImports": false
        }
    },
    "go.languageServerFlags": [
        "-rpc.trace",
        "serve",
    ],
    "go.autocompleteUnimportedPackages": false,
    "go.formatTool": "gofmt",
    "go.useLanguageServer": true,
    "go.alternateTools": {
        "go-langserver": "gopls",
      },
    "go.inferGopath": false,
    "go.gocodePackageLookupMode": "bzl",
    "workbench.editor.enablePreview": false,
    "workbench.editor.enablePreviewFromQuickOpen": false,
    "go.buildOnSave": "package",
    "go.lintOnSave": "off",
    "go.vetOnSave": "off",
    "workbench.colorTheme": "Visual Studio Dark",
    "editor.fontSize": 11,
    "terminal.integrated.fontSize": 11,
    "editor.wordWrap": "on",
    "go.toolsGopath": "~/go-code/bin"
}

[bcmills]

@ianthehat, if the assumption is that golang.org/x/tools and golang.org/x/tools/gopls are upgraded in lock-step, then versions of golang.org/x/tools that make breaking changes in dependencies used by […]/gopls should explicitly require a version of […]/gopls that is compatible with the new API.

That would avoid this sort of skew regardless of which main module gopls is built from.

[ianthehat]

No, the whole point of having a separate gopls module is to allow it to have dependencies that x/tools does not.

[ianthehat]

@shivatejesh dont worry about the 1.2 thing, that is a hard coded string from a mis-configured release, and not really a problem.
Did you restart VSCode after installing?
Did you get a gopls log in your output window?

[shivatejesh]

I did a restart, by using Cmd+Q and then started visual code.
There is no log of gopls. Here is the screenshot of output window.

[shivatejesh]

My vscode version:
Version: 1.37.1
Commit: f06011ac164ae4dc8e753a3fe7f9549844d15e35
Date: 2019-08-15T16:16:34.800Z
Electron: 4.2.7
Chrome: 69.0.3497.128
Node.js: 10.11.0
V8: 6.9.427.31-electron.0
OS: Darwin x64 18.6.0

[stamblerre]

@shivatejesh: Looks like gopls is not running at all. Do you definitely have it on your $PATH or $GOPATH? Can you run gopls -rpc.trace -v check path/to/file.go from the command line?

[hellodudu]

We don't support building gopls with any version of x/tools (or any other module we depend on) other than the versions we specify in the go.mod

On the install instructions we say

If you do want to get the latest stable version of gopls, change to any directory that is not in either your GOPATH or a module (a temp directory is fine), and use
go get golang.org/x/tools/gopls@latest

specifically to avoid triggering this case.

This works for me!

[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.)

[rifaimartin]

how to check gopls done installed?

[hyangah]

@rifaimartin check your PATH and see if one of the listed directories in the PATH contains gopls binary.