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

[adonovan]

#!stacks
"bug.Errorf" &&
 ("source.hover:133" || "golang.hover:+266")

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

[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

[findleyr]

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

[adonovan]

Well, #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.

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

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

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

[adonovan]

This stack 4fCWeg 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:+266
• 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.17.0-pre.3 go1.23.2 windows/amd64 vscode (1)