x/tools/gopls: imports: nil panic in ClearModuleInfo (via telemetry)

[adonovan]

This stack pUwreg was reported by telemetry:

ClearModuleInfo:+4 is:

		if resolverErr == nil {
			<-r.scanSema // acquire (guards caches)                            HERE
			resolver.moduleCacheCache = r.moduleCacheCache
			resolver.otherCache = r.otherCache
			r.scanSema <- struct{}{} // release
		}

but I don't see at a glance how a ModuleResolver can be constructed without a valid scanSema.

Possibly related to https://go.dev/cl/561235?

crash/crash
runtime.gopanic:+69
runtime.panicmem:=261
runtime.sigpanic:+19
golang.org/x/tools/internal/imports.(*ProcessEnv).ClearModuleInfo:+4
golang.org/x/tools/gopls/internal/cache.(*importsState).runProcessEnvFunc:+25
golang.org/x/tools/gopls/internal/cache.(*Snapshot).RunProcessEnvFunc:=439
golang.org/x/tools/gopls/internal/golang.allImportsFixes:+4
golang.org/x/tools/gopls/internal/golang.CodeActions:+13
golang.org/x/tools/gopls/internal/server.(*server).CodeAction:+95
golang.org/x/tools/gopls/internal/protocol.serverDispatch:+160
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.15.2 devel darwin/arm64 vscode (1)

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

[adonovan]

This crash is impossible according to the Go spec. I suspect a bug in the Go toolchain that was used, which is not a released one.

[adonovan]

I spoke too soon: it's a classic nil-pointer-makes-non-nil interface bug. Fix pending.

[gopherbot]

Change https://go.dev/cl/574136 mentions this issue: internal/imports: fix two "nil pointer in interface" bugs