go: x/tools/gopls: constant crashing with emacs-lsp

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

$ go version
go version go1.14.1 darwin/amd64

Does this issue reproduce with the latest release?

Currently 1.14.1 is the latest release.

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

go env Output
$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/mark/Library/Caches/go-build"
GOENV="/Users/mark/Library/Application Support/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOINSECURE=""
GONOPROXY=""
GONOSUMDB=""
GOOS="darwin"
GOPATH="/Users/mark/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/darwin_amd64"
GCCGO="gccgo"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD=""
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/03/l39qx4sd3g31crj98xtwz44h0000gn/T/go-build952685482=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

Set up gopls, emacs-lsp & lsp-ui

GO111MODULE=on go get golang.org/x/tools/gopls@latest
(autoload 'go-mode "go-mode" nil t)
(add-to-list 'auto-mode-alist '("\\.go\\'" . go-mode))
(add-hook 'go-mode-hook 'lsp-deferred)

… and trying to use Emacs for writing code

What did you expect to see?

Autocompletion etc. working without constant crashing

What did you see instead?

Emacs asking if I want to restart gopls and in *gopls::stderr*:

panic: runtime error: index out of range [0] with length 0

goroutine 5076 [running]:
golang.org/x/tools/internal/imports.(*ModuleResolver).init(0xc004132be0, 0x0, 0xc0006940c0)
	/Users/mark/go/pkg/mod/golang.org/x/tools@v0.0.0-20200316194252-fafb6e2e8a4a/internal/imports/mod.go:85 +0xfac
golang.org/x/tools/internal/imports.(*ModuleResolver).ClearForNewMod(0xc004132be0)
	/Users/mark/go/pkg/mod/golang.org/x/tools@v0.0.0-20200316194252-fafb6e2e8a4a/internal/imports/mod.go:194 +0xa2
golang.org/x/tools/internal/lsp/cache.(*view).RunProcessEnvFunc(0xc000290280, 0x1a123c0, 0xc005a352f0, 0xc006eef400, 0x0, 0x0)
	/Users/mark/go/pkg/mod/golang.org/x/tools@v0.0.0-20200316194252-fafb6e2e8a4a/internal/lsp/cache/view.go:279 +0x33f
golang.org/x/tools/internal/lsp/source.AllImportsFixes(0x1a123c0, 0xc005a352f0, 0x1a245c0, 0xc00079c060, 0x1a10a80, 0xc0002b0720, 0x0, 0xc00035ed60, 0x2, 0x2, ...)
	/Users/mark/go/pkg/mod/golang.org/x/tools@v0.0.0-20200316194252-fafb6e2e8a4a/internal/lsp/source/format.go:87 +0x479
golang.org/x/tools/internal/lsp.(*Server).codeAction(0xc00021dc80, 0x1a123c0, 0xc00595a390, 0xc005ea0780, 0xc005ea0780, 0x0, 0x0, 0x0, 0xc00466cd10)
	/Users/mark/go/pkg/mod/golang.org/x/tools@v0.0.0-20200316194252-fafb6e2e8a4a/internal/lsp/code_action.go:68 +0x8f5
golang.org/x/tools/internal/lsp.(*Server).CodeAction(0xc00021dc80, 0x1a123c0, 0xc00595a390, 0xc005ea0780, 0xc005ea0780, 0x0, 0x0, 0x1038bc3, 0x17e0260)
	/Users/mark/go/pkg/mod/golang.org/x/tools@v0.0.0-20200316194252-fafb6e2e8a4a/internal/lsp/server_gen.go:12 +0x4d
golang.org/x/tools/internal/lsp/protocol.serverHandler.Deliver(0x1a2cbc0, 0xc00021dc80, 0x1a123c0, 0xc00595a390, 0xc004291d00, 0x16e7e00, 0x1a10000)
	/Users/mark/go/pkg/mod/golang.org/x/tools@v0.0.0-20200316194252-fafb6e2e8a4a/internal/lsp/protocol/tsserver.go:433 +0x1e38
golang.org/x/tools/internal/jsonrpc2.(*Conn).Run.func1(0xc00507cde0, 0xc004291d00, 0xc000365140, 0x1a123c0, 0xc00595a390, 0x0, 0x0, 0xc005e15ea0)
	/Users/mark/go/pkg/mod/golang.org/x/tools@v0.0.0-20200316194252-fafb6e2e8a4a/internal/jsonrpc2/jsonrpc2.go:372 +0x160
created by golang.org/x/tools/internal/jsonrpc2.(*Conn).Run
	/Users/mark/go/pkg/mod/golang.org/x/tools@v0.0.0-20200316194252-fafb6e2e8a4a/internal/jsonrpc2/jsonrpc2.go:356 +0x850

Process gopls stderr finished

About this issue

  • Original URL
  • State: closed
  • Created 4 years ago
  • Comments: 18 (6 by maintainers)

Commits related to this issue

Most upvoted comments

Glad to hear the fix is in, @codesuki - thanks!

I’m going to leave this issue open to investigate why the ProcessEnv could even be created without a GOPATH. I might be able to add a regression test that has an explicitly empty GOPATH to make sure that this doesn’t happen again.

My solution was to set GOPATH etc. environment variables correctly, nothing for me to do with Bazel. 😄