x/tools/gopls: "type checker error %q outside its Fset" bug reported by telemetry

[adonovan]

This stack _5BDSg was reported by telemetry:

gopls/bug
golang.org/x/tools/gopls/internal/util/bug.report:+35
golang.org/x/tools/gopls/internal/util/bug.Reportf:+1
golang.org/x/tools/gopls/internal/cache.typeErrorsToDiagnostics.func1:+28
golang.org/x/tools/gopls/internal/cache.typeErrorsToDiagnostics:+119
golang.org/x/tools/gopls/internal/cache.(*typeCheckBatch).checkPackage:+127
golang.org/x/tools/gopls/internal/cache.(*typeCheckBatch).handleSyntaxPackage:+70
golang.org/x/tools/gopls/internal/cache.(*Snapshot).forEachPackageInternal.func2:+1
golang.org/x/sync/errgroup.(*Group).Go.func1:+3
runtime.goexit:+0

golang.org/x/tools/gopls@v0.15.0-pre.4 go1.21.5 darwin/amd64 vscode (1)

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

Dups: T_TswA ypJFHg

Closely related to:

• https://github.com/golang/go/issues/65960
• https://github.com/golang/go/issues/66765

[adonovan]

This stack T_TswA was reported by telemetry:

gopls/bug
golang.org/x/tools/gopls/internal/util/bug.report:+35
golang.org/x/tools/gopls/internal/util/bug.Reportf:+1
golang.org/x/tools/gopls/internal/cache.typeErrorsToDiagnostics.func1:+28
golang.org/x/tools/gopls/internal/cache.typeErrorsToDiagnostics:+122
golang.org/x/tools/gopls/internal/cache.(*typeCheckBatch).checkPackage:+127
golang.org/x/tools/gopls/internal/cache.(*typeCheckBatch).handleSyntaxPackage:+70
golang.org/x/tools/gopls/internal/cache.(*Snapshot).forEachPackageInternal.func2:+1
golang.org/x/sync/errgroup.(*Group).Go.func1:+3
runtime.goexit:+0

golang.org/x/tools/gopls@v0.15.3 go1.22.1 windows/amd64 vscode (1)

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

[adonovan]

Found this in passing while looking at the debug server:

gopls/internal/cache/check.go:1890: internal error: type checker error "-: cannot use _ as value or type" outside its Fset

goroutine 73634 [running]:
runtime/debug.Stack()
    /Users/adonovan/w/goroot/src/runtime/debug/stack.go:26 +0x64
golang.org/x/tools/gopls/internal/util/bug.report({0x1400da1e5a0, 0x56})
    /Users/adonovan/w/xtools/gopls/internal/util/bug/bug.go:91 +0xd4
golang.org/x/tools/gopls/internal/util/bug.Reportf({0x1037db194?, 0x1401bf536d8?}, {0x1401bf53748?, 0x1d?, 0x103affe00?})
    /Users/adonovan/w/xtools/gopls/internal/util/bug/bug.go:54 +0x28
golang.org/x/tools/gopls/internal/cache.typeErrorsToDiagnostics.func1({0x1401bf538b0, 0x1, 0x12b862290?})
    /Users/adonovan/w/xtools/gopls/internal/cache/check.go:1890 +0xaec
golang.org/x/tools/gopls/internal/cache.typeErrorsToDiagnostics(0x0?, {0x14014711600?, 0x1400c27cf50?, 0x41?}, {0x10377161b?, 0x5?}, 0xa0?, 0x54?)
    /Users/adonovan/w/xtools/gopls/internal/cache/check.go:2004 +0xfc
golang.org/x/tools/gopls/internal/cache.(*typeCheckBatch).checkPackage(0x1400b568de0, {0x103c4e168, 0x14014229620}, 0x14013409c20)
    /Users/adonovan/w/xtools/gopls/internal/cache/check.go:1592 +0xae8
golang.org/x/tools/gopls/internal/cache.(*typeCheckBatch).handleSyntaxPackage(0x1400b568de0, {0x103c4e168, 0x14014229620}, 0x0, {0x14000e72ba0, 0x56})
    /Users/adonovan/w/xtools/gopls/internal/cache/check.go:567 +0x534
golang.org/x/tools/gopls/internal/cache.(*Snapshot).forEachPackageInternal.func2()
    /Users/adonovan/w/xtools/gopls/internal/cache/check.go:418 +0x34
golang.org/x/sync/errgroup.(*Group).Go.func1()
    /Users/adonovan/go/pkg/mod/golang.org/x/sync@v0.7.0/errgroup/errgroup.go:78 +0x58
created by golang.org/x/sync/errgroup.(*Group).Go in goroutine 71449
    /Users/adonovan/go/pkg/mod/golang.org/x/sync@v0.7.0/errgroup/errgroup.go:75 +0x98

Will try to repro.

[adonovan]

No luck so far. The crash indicates a referring ast.Ident{Name: "_"} with a Pos that is invalid, either because it is 0 or out of the FileSet range. I don't see see how the parser can create one; its conceivable that fixAST could: for example, fixInitStmt tries to resolve if i := 0 at EOF by parsing the text i := 0 (a BadExpr) as a statement, but it does so in a throwaway FileSet, so the resulting positions are garbage. They are likely small values, which have a high chance of being valid positions in the first file of an ordinary FileSet, but the specific FileSet constructed by gopls' type checking is a synthetic one that cherry picks the files only of the current type-checking batch, so it may have a gap at the bottom.

[adonovan]

This stack T_TswA was reported by telemetry:

gopls/bug
golang.org/x/tools/gopls/internal/util/bug.report:+35
golang.org/x/tools/gopls/internal/util/bug.Reportf:+1
golang.org/x/tools/gopls/internal/cache.typeErrorsToDiagnostics.func1:+28
golang.org/x/tools/gopls/internal/cache.typeErrorsToDiagnostics:+122
golang.org/x/tools/gopls/internal/cache.(*typeCheckBatch).checkPackage:+127
golang.org/x/tools/gopls/internal/cache.(*typeCheckBatch).handleSyntaxPackage:+70
golang.org/x/tools/gopls/internal/cache.(*Snapshot).forEachPackageInternal.func2:+1
golang.org/x/sync/errgroup.(*Group).Go.func1:+3
runtime.goexit:+0

golang.org/x/tools/gopls@v0.15.3 go1.22.1 windows/amd64 vscode (1)

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

[adonovan]

This stack ypJFHg was reported by telemetry:

gopls/bug
golang.org/x/tools/gopls/internal/util/bug.report:+35
golang.org/x/tools/gopls/internal/util/bug.Reportf:+1
golang.org/x/tools/gopls/internal/cache.typeErrorsToDiagnostics.func1:+34
golang.org/x/tools/gopls/internal/cache.typeErrorsToDiagnostics:+153
golang.org/x/tools/gopls/internal/cache.(*typeCheckBatch).checkPackage:+128
golang.org/x/tools/gopls/internal/cache.(*typeCheckBatch).handleSyntaxPackage:+70
golang.org/x/tools/gopls/internal/cache.(*Snapshot).forEachPackageInternal.func2:+1
golang.org/x/sync/errgroup.(*Group).Go.func1:+3
runtime.goexit:+0

golang.org/x/tools/gopls@v0.16.0-pre.1 go1.22.0 linux/amd64 vscode (1)
golang.org/x/tools/gopls@v0.16.0-pre.2 go1.22.4 linux/amd64 vscode (1)

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