x/tools/gopls: Hover: panic in lookup{ObjectByName,DocLinkSymbol}

[adonovan]

#!stacks
("bug.Reportf" || "runtime.sigpanic") &&
   ("lookupObjectByName" || "lookupDocLinkSymbol")

Issue created by stacks.

func lookupObjectByName(pkg *cache.Package, pgf *parsego.File, name string) types.Object {
	scope := pkg.Types().Scope()
	fileScope := pkg.TypesInfo().Scopes[pgf.File]
	pkgName, suffix, _ := strings.Cut(name, ".")
	obj, ok := fileScope.Lookup(pkgName).(*types.PkgName) // <--- panic

Variant after the function was renamed:

func lookupDocLinkSymbol(pkg *cache.Package, pgf *parsego.File, name string) types.Object {
	scope := pkg.Types().Scope()

	prefix, suffix, _ := strings.Cut(name, ".")

	// Try treating the prefix as a package name,
	// allowing for non-renaming and renaming imports.
	fileScope := pkg.TypesInfo().Scopes[pgf.File]
	if fileScope == nil {
		// This is theoretically possible if pgf is a GoFile but not a
		// CompiledGoFile. However, we do not know how to produce such a package
		// without using an external GoPackagesDriver.
		// See if this is the source of golang/go#70635
		if slices.Contains(pkg.CompiledGoFiles(), pgf) {
			bug.Reportf("missing file scope for compiled file")  //  <--- reached
		} else {
			bug.Reportf("missing file scope for non-compiled file")
		}

This stack l9BGAQ was reported by telemetry:

• crash/crash
• runtime.gopanic:+69
• runtime.panicmem:=262
• runtime.sigpanic:+19
• go/types.(*Scope).Lookup:+10
• golang.org/x/tools/gopls/internal/golang.lookupObjectByName:+4
• golang.org/x/tools/gopls/internal/golang.parseDocLink:+58
• golang.org/x/tools/gopls/internal/golang.hover:+43
• 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.23.0 linux/amd64 vscode (1)

Dups: z79pXw p3-DZQ oHmaZg 5F-J2A UxUyAQ

[gabyhelp]

Related Issues and Documentation

• x/tools/gopls: crash in Hover (telemetry) #69362
• x/tools/gopls: panic in hover #52211 (closed)
• x/tools/gopls: FindFileInPackage nil pointer dereference #38100 (closed)
• x/tools/gopls: crash in packageReferences (reported by telemetry) #66250 (closed)
• x/tools/gopls: automated issue report (crash) #44300 (closed)
• x/tools/gopls: crash in signature help on error.Error #63578 (closed)
• x/tools/gopls: automated issue report (crash) #48492 (closed)
• gopls: automated issue report (crash) #40464 (closed)
• x/tools/gopls: panic in mod.hoverOnModuleStatement #59077 (closed)
• x/tools/gopls: automated issue report (crash) #40449 (closed)

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

[adonovan]

This is mysterious. The crash is in go/types.(*Scope).Lookup on this line:

func (s *Scope) Lookup(name string) Object {
	obj := resolve(name, s.elems[name])
	if obj == universeAnyAlias && !aliasAny() { // <---------- panic
		return universeAnyNoAlias
	}
	return obj
}

but the only way that line can panic (short of a compiler error that causes the wrong line to be reported) is if obj is a types.Object value of the same concrete type as universeAnyAlias and that concrete type does not support == comparison. However, universeAnyAlias clearly has type *TypeName, a pointer, which supports == comparison. (And presumably resolve also returns only pointers to various struct types).

[findleyr]

I do not understand how this crash is possible, and so suggest that we move it to the next milestone and see if it reoccurs in v0.17.0.

[adonovan]

@dr2chase Got any ideas how this crash could possibly occur?