x/tools/gopls: types.IsInterface "Named.check == nil but type is incomplete" panic in methodsets.EnsurePointer

[adonovan]

#!stacks
"runtime.gopanic" && "types.IsInterface" && "methodsets.EnsurePointer:+1"

Issue created by stacks.

The Named type passed to IsInterface has an Underlying type that is also a Named (indicating type checking is incomplete) yet the original Named (which may or may not be the same) has Named.check==nil (indicating type checking should be complete). This seems like a go/types bug.

This stack pY1Q7g was reported by telemetry:

• crash/crash
• runtime.gopanic:+69
• go/types.(*Named).under:+21
• go/types.under:+2
• go/types.IsInterface:=111
• golang.org/x/tools/gopls/internal/cache/methodsets.EnsurePointer:+1
• golang.org/x/tools/gopls/internal/cache/methodsets.methodSetInfo:+4
• golang.org/x/tools/gopls/internal/cache/methodsets.(*indexBuilder).build:+35
• golang.org/x/tools/gopls/internal/cache/methodsets.NewIndex:=82
• golang.org/x/tools/gopls/internal/cache.(*syntaxPackage).methodsets.func1:+1
• sync.(*Once).doSlow:+5
• sync.(*Once).Do:=67
• golang.org/x/tools/gopls/internal/cache.(*syntaxPackage).methodsets:+1
• golang.org/x/tools/gopls/internal/cache.storePackageResults:+3
• golang.org/x/tools/gopls/internal/cache.(*typeCheckBatch).handleSyntaxPackage.gowrap1:+0
• runtime.goexit:+0

golang.org/x/tools/[email protected] go1.23.0 linux/amd64 neovim (1)

[gabyhelp]

Related Issues and Documentation

• x/tools/gopls: panic in methodsets.NewIndex #60628 (closed)
• x/tools/gopls: types.Func.typ=nil panic in missingMethod with gopls@master built with go@master #59848 (closed)
• go.tools/go.types: goto _ crashes type checker #7537 (closed)
• go/types, types2: gopls crash in computeInterfaceTypeSet with "duplicate method" #51316 (closed)
• x/tools/gopls: interface conversion: types.Object is *types.Var, not *types.Func #67975 (closed)
• x/tools/gopls: respect go/analysis.Pass.RunDespiteErrors #33689 (closed)
• go/types, types2: gopls crash on method with type parameters #50427 (closed)
• x/tools/gopls: panic in OriginMethod #61196 (closed)
• go/types: interface.Complete panics for interfaces with duplicate methods #61737 (closed)
• x/tools/gopls: panic in analyzer due to type checker errors #32413 (closed)

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

[adonovan]

cc: @griesemer @timothy-king

[findleyr]

This is liable to be very hard to track down without a reproducer. I'm glad we have this assertion.

Some brief notes, from refreshing my memory:

• Named types are only created in go/types via Checker.newNamed and Checker.newNamedInstance, both of which should register the type as needing cleanup.
• At cleanup time (at the end of type checking), non-instantiated named types should have under called with a non-nil checker. Unresolved instances are skipped if their underlying has not yet been resolved, but their origin should be cleaned up, so when they do resolve their underlying it should be substituted in the origin underlying, which will not be a Named type.
• Importers use types.NewNamed, which panic if the underlying is named.

So, once type checking or importing exits, all types should either have non-Named underlying, or be an unexpanded instance of a type that has a non-Named underlying. That's how it's supposed to work. Aliases add a layer of complexity, but shouldn't be relevant to [email protected] (which does not have the Go 1.23.1 language version).

Therefore, it's concerning that there must really be something we've missed here. One possibility is a path to newNamed or newNamedInstance during type checking where the Checker is actually nil (unfortunately, many methods on Checker accept a nil receiver). However I do not see such a path.

A good next step might be to add some earlier assertions of the invariants described above.

[findleyr]

Another potential category of bug would be some sort of ordering bug, such that the instance is expanded after it has been cleaned up. But this logic is meant to prevent such a scenario: whenever the named type is expanded, it is verified that it either has non-named underlying OR is still yet to be cleaned up (check != nil => not cleaned up yet).

[findleyr]

Ah, I wonder if this could actually be a dupe of #68877. Could it be that someone built gopls with the explicit GODEBUG=gotypesalias=1 setting?

[findleyr]

Absent more information, I think we should assume this is a dupe of #68877. We should reopen only if this occurs with go1.23.1 or later.