Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

x/tools/gopls: Hover bug reported by telemetry #64241

Open
adonovan opened this issue Nov 17, 2023 · 6 comments
Open

x/tools/gopls: Hover bug reported by telemetry #64241

adonovan opened this issue Nov 17, 2023 · 6 comments
Assignees
@adonovan
Labels
gopls/telemetry-wins gopls Issues related to the Go language server, gopls. NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. Tools This label describes issues relating to any tools in the x/tools repository.
Milestone
gopls/v0.16.0

Comments

@adonovan
Copy link
Member

adonovan commented Nov 17, 2023 •
edited

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.
@gopherbot gopherbot added Tools This label describes issues relating to any tools in the x/tools repository. gopls Issues related to the Go language server, gopls. labels Nov 17, 2023
@gopherbot gopherbot added this to the Unreleased milestone Nov 17, 2023
@adonovan adonovan added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Nov 17, 2023
@adonovan adonovan changed the title x/tools/gopls: Hover bug reported by telemetry [A-IqbA] x/tools/gopls: Hover bug reported by telemetry Nov 17, 2023
@findleyr findleyr modified the milestones: Unreleased, gopls/v0.15.0 Nov 17, 2023
@adonovan
Copy link
Member Author

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

@findleyr findleyr self-assigned this Nov 22, 2023
@adonovan
Copy link
Member Author

adonovan commented Dec 11, 2023 •
edited

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.

@findleyr findleyr removed their assignment Jan 22, 2024
@adonovan
Copy link
Member Author

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.

@adonovan adonovan self-assigned this Jan 24, 2024
@gopherbot
Copy link

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

@findleyr
Copy link
Contributor

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

@findleyr findleyr modified the milestones: gopls/v0.15.0, gopls/v0.16.0 Jan 24, 2024
gopherbot pushed a commit to golang/tools that referenced this issue Jan 24, 2024
@adonovan
gopls/internal/golang: don't bug.Report repaired ASTs in hover
35d8b1b 
Updates golang/go#64241

Change-Id: If799f3454f628421f03f055eb003442bb90fe656
Reviewed-on: https://go-review.googlesource.com/c/tools/+/558255
Reviewed-by: Robert Findley <rfindley@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
@adonovan adonovan mentioned this issue Mar 14, 2024
Closed
@adonovan
Copy link
Member Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@adonovan adonovan

Labels
gopls/telemetry-wins gopls Issues related to the Go language server, gopls. NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. Tools This label describes issues relating to any tools in the x/tools repository.
Projects
None yet
Milestone
gopls/v0.16.0
Development

No branches or pull requests
3 participants
@adonovan @gopherbot @findleyr