Skip to content

x/tools/gopls: crash due to missing type in inline.escape #75236

@adonovan

Description

@adonovan
#!stacks
"sigpanic" && "inline.escape.func1:+27"

Issue created by stacks.

This stack PHhF6w was reported by telemetry:

	case *ast.SelectorExpr:
			// We assume TypeOf returns non-nil.
			if _, ok := info.TypeOf(e.X).Underlying().(*types.Struct); ok {  <---- panic
				lvalue(e.X, escapes) // &s.f on struct
			}

The question here is why is this panic not recovered? The stack is truncated so we can't tell whether inline.Inline was called on behalf of golang.inlineCall golang.inlineAllCalls, or gofix.(*analyzer) inlineCall. However, the first two conditionally call recover if there was a type error in the caller or callee packages, and the third doesn't run on ill-typed code. So either there is a bug in the type checker that causes it to fail to record a type, or more likely, the recover condition is too strict: perhaps the type error is in a transitive dependency. The fix in that case is to compute a "transitively error-free" predicate over packages and call recover if it is false. FWIW, the deprecated go/loader had this feature; perhaps go/packages should too (though it can be derived).

golang.org/x/tools/[email protected] go1.24.4 darwin/arm64 vscode (2)

Metadata

Metadata

Assignees

No one assigned

    Labels

    NeedsInvestigationSomeone must examine and confirm this is a valid issue and not a duplicate of an existing one.ToolsThis label describes issues relating to any tools in the x/tools repository.goplsIssues related to the Go language server, gopls.gopls/telemetry-wins

    Type

    No type

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions