#!stacks
"sigpanic" && "inlineVariableOne-range1"

Issue created by stacks.

        id := curIdent.Node().(*ast.Ident)
        obj1 := info.Uses[id]
        _, obj2 := scope.LookupParent(id.Name, pos)
        if obj1 != obj2 {
            return nil, nil, fmt.Errorf("cannot inline variable: its initializer expression refers to %q, which is shadowed by the declaration at line %d", id.Name, safetoken.Position(pgf.Tok, obj2.Pos()).Line) // <----------- obj2 is nil
        }

This stack tdbvkw was reported by telemetry:

golang.org/x/tools/gopls@v0.19.1 go1.25rc1 darwin/arm64 other,vscode (3)

Dups: BPia1w srVy-g ZsJ7Vw PPnIfw dPhsZQ 46y2Vg

Comment From: adonovan

The faulting instruction is the retrieval of obj2.Pos from the types.Object itable, meaning that obj2 is nil or invalid. (Yay for PC values!) If obj2 is nil, this means obj1 is non-nil, so we must have an input of the form:

func f(y int) {
       var x = y // y is a valid reference (to obj1)
       {
               y := 2
               println(x) <-- invoke inline-variable on x
               _ = y
       }
}

but somehow the LookupParent("y") operation at println(x) fails to find any object. I don't see how this can happen, because the environment at that point must define a superset of the names defined at var x = y. So this cannot happen.

Therefore, this must be caused by memory corruption of obj2. Ugh, I hate this.

Comment From: adonovan

Having just written "this cannot happen", like a bull to a red flag I sought to disprove myself, and did so easily: what if the set of free names that we loop over is too large, and includes names that are not free? This seems easily possible. Example:

func f() {
       var x = func(notfree int) { _ = notfree }
       println(x) <-- invoke inline-variable on x
}

Lo and behold gopls crashes. Not memory corruption, just bad code. Yay.

Comment From: gopherbot

Change https://go.dev/cl/683535 mentions this issue: gopls/internal/golang: fix crash in refactor.inline.variable

Comment From: gabyhelp

Related Issues

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

Comment From: adonovan

This stack BPia1w was reported by telemetry:

golang.org/x/tools/gopls@v0.19.1 go1.24.4 linux/amd64 other (1)

Comment From: adonovan

This stack srVy-g was reported by telemetry:

golang.org/x/tools/gopls@v0.19.1 go1.24.4 windows/amd64 vscode (2)

Comment From: adonovan

This stack ZsJ7Vw was reported by telemetry:

golang.org/x/tools/gopls@v0.19.1 go1.24.4 darwin/arm64 other,vscode (2)

Comment From: adonovan

This stack PPnIfw was reported by telemetry:

golang.org/x/tools/gopls@v0.20.0-pre.1 go1.24.4 darwin/arm64 vscode (1)

Comment From: adonovan

Latest stack implicates obj2.Pos() where obj2 is nil, in inlineVariableOne.

Comment From: adonovan

This stack dPhsZQ was reported by telemetry:

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

Comment From: adonovan

This stack 46y2Vg was reported by telemetry:

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