#!stacks
"bug.Errorf" &&
 ("source.hover:133" ||
   "golang.hover:+266" ||  /* v0.14.1 - v0.17.0-pre.3 */
   "golang.hover:+272" || /* v0.18.0-pre.1 */
   "golang.hover:+299" ) /* v0.19.0-pre.3 */

This stack A-IqbA was reported by telemetry:

hover:133 is https://cs.opensource.google/go/x/tools/+/refs/tags/gopls/v0.14.1:gopls/internal/lsp/source/hover.go;l=225 is

return protocol.Range{}, nil, bug.Errorf("type name %q without type spec", obj.Name())

gopls/bug
golang.org/x/tools/gopls/internal/bug.report:35
golang.org/x/tools/gopls/internal/bug.Errorf:2
golang.org/x/tools/gopls/internal/lsp/source.hover:133
golang.org/x/tools/gopls/internal/lsp/source.Hover:4
golang.org/x/tools/gopls/internal/lsp.(*Server).hover:18
golang.org/x/tools/gopls/internal/lsp.(*Server).Hover:1
golang.org/x/tools/gopls/internal/lsp/protocol.serverDispatch:300
golang.org/x/tools/gopls/internal/lsp/lsprpc.(*StreamServer).ServeStream.ServerHandler.func3:5
golang.org/x/tools/gopls/internal/lsp/lsprpc.(*StreamServer).ServeStream.handshaker.func4:52
golang.org/x/tools/gopls/internal/lsp/protocol.Handlers.MustReplyHandler.func1:2
golang.org/x/tools/gopls/internal/lsp/protocol.Handlers.AsyncHandler.func2.2:3
runtime.goexit:0

golang.org/x/tools/gopls@devel devel linux/amd64 (1)
golang.org/x/tools/gopls@v0.14.1 go1.21.3 darwin/arm64 (1)

Reported using golang.org/x/tools/gopls/internal/telemetry/cmd/stacks.

Dups: G_PnXA gzmDpA 4fCWeg ZK-TGQ LFKY3g 3ayQew

Comment From: adonovan

This stack indicates that obj is a TypeName (Name or alias, but not a TypeParam), but the spec returned by findDeclInfo was not a TypeSpec. I can't explain how this can happen. (At first I assume it was due to obj.Pos() being NoPos, which can happen for "unsafe" package members; they are not caught by the obj.Pkg() == nil check because they do have a package. That is indeed a bug, but it's not this bug.)

Comment From: adonovan

Conceivably another case of AST fixing perturbing positions? (See related #64479.) In any case, all callers of findDeclInfo should probably handle a nil result instead of assuming that it always succeeds.

Comment From: adonovan

I wrote a program that ran findDeclInfo on every TypeName in kubernetes plus its dependencies, and not a single call returned spec=nil. This lends support to the idea that it's related to ill-formed files and AST repair.

Comment From: gopherbot

Change https://go.dev/cl/558255 mentions this issue: gopls/internal/golang: don't bug.Report repaired ASTs in hover

Comment From: findleyr

Thanks for investigating. With the above CL, this is good to bump to v0.16.

Comment From: adonovan

Well, https://github.com/golang/go/issues/66314 shows that AST repair is not to blame.

One thought: is this an alias to a TypeParam, and therefore not a TypeParam under the GODEBUG=gotypesaliases=1 regime? But the version string says v0.15.1, and (IIUC) a user-built binary with a GODEBUG, even at that exact commit, would not have that version.

Comment From: adonovan

This stack G_PnXA was reported by telemetry:

gopls/bug
golang.org/x/tools/gopls/internal/util/bug.report:+35
golang.org/x/tools/gopls/internal/util/bug.Errorf:+2
golang.org/x/tools/gopls/internal/golang.hover:+224
golang.org/x/tools/gopls/internal/golang.Hover:+4
golang.org/x/tools/gopls/internal/server.(*server).Hover:+30
golang.org/x/tools/gopls/internal/protocol.serverDispatch:+335
golang.org/x/tools/gopls/internal/lsprpc.(*streamServer).ServeStream.ServerHandler.func3:+5
golang.org/x/tools/gopls/internal/lsprpc.(*streamServer).ServeStream.handshaker.func4:+52
golang.org/x/tools/gopls/internal/protocol.Handlers.MustReplyHandler.func1:+2
golang.org/x/tools/gopls/internal/protocol.Handlers.AsyncHandler.func2.2:+3
runtime.goexit:+0

golang.org/x/tools/gopls@v0.16.1 go1.22.5 darwin/arm64 vscode (2)
golang.org/x/tools/gopls@v0.16.1 go1.22.4 darwin/amd64 (1)

Issue created by golang.org/x/tools/gopls/internal/telemetry/cmd/stacks.

Comment From: adonovan

This stack gzmDpA was reported by telemetry:

gopls/bug
golang.org/x/tools/gopls/internal/util/bug.report:+35
golang.org/x/tools/gopls/internal/util/bug.Errorf:+2
golang.org/x/tools/gopls/internal/golang.hover:+224
golang.org/x/tools/gopls/internal/golang.Hover:+4
golang.org/x/tools/gopls/internal/server.(*server).Hover:+30
golang.org/x/tools/gopls/internal/protocol.serverDispatch:+335
golang.org/x/tools/gopls/internal/protocol.ServerHandler.func1:+5
golang.org/x/tools/gopls/internal/lsprpc.handshaker.func1:+52
golang.org/x/tools/internal/jsonrpc2.MustReplyHandler.func1:+2
golang.org/x/tools/internal/jsonrpc2.AsyncHandler.func1.2:+3
runtime.goexit:+0

golang.org/x/tools/gopls@v0.16.1 go1.20.7 darwin/arm64 other,vscode (2)

Issue created by golang.org/x/tools/gopls/internal/telemetry/cmd/stacks.

Comment From: findleyr

Still no idea what could cause this, short of a bug in findDeclInfo.

Note that in gopls@v0.16.1, we were already using Unalias, so something related to type parameters and Unalias seems unlikely.

This hasn't recurred recently, even with many gopls users, so let's wait and see.

Comment From: adonovan

This stack 4fCWeg was reported by telemetry:

golang.org/x/tools/gopls@v0.17.0-pre.3 go1.23.2 windows/amd64 vscode (1)

Comment From: adonovan

This stack ZK-TGQ was reported by telemetry:

golang.org/x/tools/gopls@v0.18.0-pre.1 go1.23.6 darwin/arm64 other,vscode (1)

Comment From: adonovan

This stack LFKY3g was reported by telemetry:

golang.org/x/tools/gopls@v0.19.0-pre.3 go1.24.4 darwin/arm64 other,vscode (1)

This stack 3ayQew was reported by telemetry:

golang.org/x/tools/gopls@v0.19.0-pre.2 go1.24.3 darwin/arm64 other,vscode (4)
golang.org/x/tools/gopls@v0.19.0-pre.2 go1.24.4 darwin/arm64 other,vscode (1)