#!stacks
"sigpanic" && "go/types.(*Checker).exprInternal:+156" && "go/types.(*Checker).binary:+4"

Issue created by stacks.

The type checker panics in its default case. This means one of:

• the type switch is non-exhaustive. But that's not the case, as the only ast.Expr types in gopls (according to gopls) are those defined in the go/ast package, for which the type switch is complete;
• e is nil. This is unexpected, but go/types ought not to panic while constructing the panic message. The value of e comes from BinaryExpr.Y. For BinaryExprs originating in the parser, the Y field is always non-nil even on case of parse error. The only other BinaryExpr values constructed within gopls are from the inliner's falcon analysis. Looking over all 4 composite literals, three are dominated by a check of Y != nil. One is not. That seems like a bug. [Actually, all four.] However, the falcon constraint expressions are type-checked by CheckExpr, so the presence of funcDecl on the call stack rejects that theory, leaving:
• e is an invalid non-nil pointer and we're looking at memory corruption or bad hardware.

This stack ElUPug was reported by telemetry:

• crash/crash
• runtime.throw:+9,+0x47
• runtime.sigpanic:+33,+0x26b
• go/types.(*Checker).exprInternal:+156,+0xa4b
• go/types.(*Checker).rawExpr:+10,+0x18b
• go/types.(*Checker).expr:+1,+0x2f
• go/types.(*Checker).binary:+4,+0xcb
• go/types.(*Checker).exprInternal:+135,+0x6bd
• go/types.(*Checker).rawExpr:+10,+0x18b
• go/types.(*Checker).expr:+1,+0x2f
• go/types.(*Checker).stmt:+212,+0x2a4
• go/types.(*Checker).stmtList:+9,+0x84
• go/types.(*Checker).stmt:+204,+0x171
• go/types.(*Checker).stmt:+223,+0x2fc9
• go/types.(*Checker).stmtList:+9,+0x84
• go/types.(*Checker).funcBody:+24,+0x310
• go/types.(*Checker).funcDecl.func1:+1,+0x39

golang.org/x/tools/gopls@v0.20.0 go1.24.7 linux/amd64 vscode (1)