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.

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

x/tools/gopls: ast.StructType has type other than types.StructType (no type?) #69150

Open
adonovan opened this issue Aug 29, 2024 · 4 comments
Open
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

Comments

@adonovan
Copy link
Member

adonovan commented Aug 29, 2024

This stack iWGuoA was reported by telemetry:

xtools/gopls/internal/golang/hover.go:

	if v, ok := obj.(*types.Var); ok && v.IsField() {
		// Find enclosing struct type.
		var tStruct *types.Struct
		for _, n := range path {
			if n, ok := n.(*ast.StructType); ok {
				tStruct = pkg.TypesInfo().TypeOf(n).(*types.Struct) // type assertion failed
				break
			}
		}

I think this must mean TypeOf returned nil (some other type for ast.StructType seems unlikely). If so, the underlying bug is in the type checker.

crash/crash
runtime.gopanic:+69
runtime.panicdottypeE:=275
runtime.panicdottypeI:+5
golang.org/x/tools/gopls/internal/golang.computeSizeOffsetInfo:+40
golang.org/x/tools/gopls/internal/golang.hover:+186
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/[email protected] go1.23.0 darwin/arm64 vscode (1)

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

@adonovan adonovan added NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. gopls Issues related to the Go language server, gopls. Tools This label describes issues relating to any tools in the x/tools repository. gopls/telemetry-wins labels Aug 29, 2024
@gopherbot gopherbot added this to the Unreleased milestone Aug 29, 2024
@adonovan adonovan modified the milestones: Unreleased, gopls/v0.17.0 Aug 29, 2024
@adonovan
Copy link
Member Author

@timothy-king @griesemer

@adonovan
Copy link
Member Author

adonovan commented Aug 29, 2024

@findleyr points out that this is likely a consequence of #69092, which doesn't set the types for the inside of a CompositeLit. If the StructType happens to be within it, then we get the above crash.

See #68918 (comment), which anticipates the likely need for adding a number of workarounds for crashes from the same underlying cause as they show up.

@findleyr
Copy link
Contributor

I'm not sure that's the only way to reach this crash, but it does seem like we can the known bug in CompositeLit type checking to write a test, and fix by making gopls more defensive.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
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
Development

No branches or pull requests

4 participants