x/tools/gopls: "type name %q without type spec" bug in Hover (via telemetry)

[adonovan]

#!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 x237tQ Qt7hPw WnsSnA

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

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

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

[gopherbot]

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