x/tools/gopls: panic every time at Error() function, when 'error' inherited by another interface

[ziposcar]

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

$ go version go1.17 linux/amd64

Does this issue reproduce with the latest release?

Yes

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

go env Output

$ go env
GO111MODULE="on"
GOARCH="amd64"
GOBIN=""
GOCACHE="---"
GOENV="---"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="---"
GONOPROXY="---"
GONOSUMDB="---"
GOOS="linux"
GOPATH="---"
GOPRIVATE="---"
GOPROXY="---,direct"
GOROOT="/opt/tiger/go/go"
GOSUMDB="sum.golang.google.cn"
GOTMPDIR=""
GOTOOLDIR="/opt/tiger/go/go/pkg/tool/linux_amd64"
GOVCS=""
GOVERSION="go1.17"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
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 -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build4272361125=/tmp/go-build -gno-record-gcc-switches"
("---" for private info)

What did you do?

$ gopls references main.go:9:11

(the second "Error")
for the following codes:

main.go:

package main

type T interface {
	error
}

type S struct{}

func (*S) Error() string {
	return ""
}

func main() {
	var s S
	_ = s.Error()
}

go.mod:

module github.com/demo

go 1.17

$ pwd
$GOPATH/src/github.com/demo

$tree
.
├── go.mod
└── main.go

What did you expect to see?

$GOPATH/src/github.com/demo/main.go:15:8-13

What did you see instead?

Gopls panic with following message and stack info:

panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x20 pc=0x7c9b8e]

goroutine 13813 [running]:
golang.org/x/tools/internal/lsp/source.references({0xe96cc0, 0xc085ba3560}, {0xebfcc0, 0xc034a39c00}, {0xc04cf170c8, 0x1, 0x44}, 0x0, 0x0, 0x0)
	$GOPATH/pkg/mod/golang.org/x/tools@v0.1.6-0.20210908190839-cf92b39a962c/internal/lsp/source/references.go:72 +0x1ce
golang.org/x/tools/internal/lsp/source.interfaceReferences({0xe96cc0, 0xc085ba3560}, {0xebfcc0, 0xc034a39c00}, {0xea2dd8, 0xc0353fc060}, {0x1ef865d0, 0xc0})
	$GOPATH/pkg/mod/golang.org/x/tools@v0.1.6-0.20210908190839-cf92b39a962c/internal/lsp/source/references.go:178 +0x229
golang.org/x/tools/internal/lsp/source.references({0xe96cc0, 0xc085ba3560}, {0xebfcc0, 0xc034a39c00}, {0xc088f86340, 0x1, 0xc000510a50}, 0x1, 0x1, 0x0)
	$GOPATH/pkg/mod/golang.org/x/tools@v0.1.6-0.20210908190839-cf92b39a962c/internal/lsp/source/references.go:155 +0xd85
golang.org/x/tools/internal/lsp/source.References({0xe96c18, 0xc088f80740}, {0xebfcc0, 0xc034a39c00}, {0xea2dd8, 0xc0353fc060}, {0x35ae4418, 0xc0}, 0x1)
	$GOPATH/pkg/mod/golang.org/x/tools@v0.1.6-0.20210908190839-cf92b39a962c/internal/lsp/source/references.go:45 +0x1cb
golang.org/x/tools/internal/lsp.(*Server).references(0xc035ae4418, {0xe96c18, 0xc088f80740}, 0xc088f862c0)
	$GOPATH/pkg/mod/golang.org/x/tools@v0.1.6-0.20210908190839-cf92b39a962c/internal/lsp/references.go:24 +0x12a
golang.org/x/tools/internal/lsp.(*Server).References(0xc012332000, {0xe96c18, 0xc088f80740}, 0xbfab60)
	$GOPATH/pkg/mod/golang.org/x/tools@v0.1.6-0.20210908190839-cf92b39a962c/internal/lsp/server_gen.go:184 +0x25
golang.org/x/tools/internal/lsp/protocol.serverDispatch({0xe96c18, 0xc088f80740}, {0xec3e40, 0xc000250900}, 0xc085ba3350, {0xe96e80, 0xc088f80500})
	$GOPATH/pkg/mod/golang.org/x/tools@v0.1.6-0.20210908190839-cf92b39a962c/internal/lsp/protocol/tsserver.go:393 +0x1c5a
golang.org/x/tools/internal/lsp/protocol.ServerHandler.func1({0xe96c18, 0xc088f80740}, 0xc085ba3350, {0xe96e80, 0xc088f80500})
	$GOPATH/pkg/mod/golang.org/x/tools@v0.1.6-0.20210908190839-cf92b39a962c/internal/lsp/protocol/protocol.go:154 +0x90
golang.org/x/tools/internal/lsp/lsprpc.handshaker.func1({0xe96c18, 0xc088f80740}, 0xc085ba3350, {0xe96e80, 0xc088f80500})
	$GOPATH/pkg/mod/golang.org/x/tools@v0.1.6-0.20210908190839-cf92b39a962c/internal/lsp/lsprpc/lsprpc.go:506 +0xa7d
golang.org/x/tools/internal/jsonrpc2.MustReplyHandler.func1({0xe96c18, 0xc088f80740}, 0xc08c146a20, {0xe96e80, 0xc088f80500})
	$GOPATH/pkg/mod/golang.org/x/tools@v0.1.6-0.20210908190839-cf92b39a962c/internal/jsonrpc2/handler.go:35 +0xf6
golang.org/x/tools/internal/jsonrpc2.AsyncHandler.func1.2()
	$GOPATH/pkg/mod/golang.org/x/tools@v0.1.6-0.20210908190839-cf92b39a962c/internal/jsonrpc2/handler.go:103 +0xa3
created by golang.org/x/tools/internal/jsonrpc2.AsyncHandler.func1
	$GOPATH/pkg/mod/golang.org/x/tools@v0.1.6-0.20210908190839-cf92b39a962c/internal/jsonrpc2/handler.go:100 +0x20f

[ziposcar]

I tried another way, the same panic appeared again:

package main

type T error

type S struct{}

func (*S) Error() string {
	return ""
}

func main() {
	var s S
	_ = s.Error()
}

$ gopls references main.go:7:11

[ziposcar]

Just remove the T interface can help.

[stamblerre]

Thanks for reporting this! I can reproduce and will investigate.

[gopherbot]

Change https://golang.org/cl/350132 mentions this issue: internal/lsp: fix panic in find references on Error

[ziposcar]

I understand the fix commit . But why following codes can find references for Error? The S struct is also an implement of error interface.

package main
/*
type T interface {
	error
}
*/
type S struct{}

func (*S) Error() string {
	return ""
}

func main() {
	var s S
	_ = s.Error()
}

[stamblerre]

Error is a special case, which means that we would have to add special code just to handle it specifically. I'm not even sure if it's possible to do, but we could investigate it. error types are also very common in a codebase, so we figured it wouldn't be very necessary for users to find references on it. If you feel differently, please file a new issue, and we can consider a solution.