go/types: assertion failure in recent range statement checking logic

[lmorg]

gopls version: v0.16.1/go1.22.5 gopls flags: update flags: proxy extension version: 0.41.4 environment: Visual Studio Code darwin initialization error: undefined issue timestamp: Fri, 05 Jul 2024 22:28:48 GMT restart history: Fri, 05 Jul 2024 21:41:59 GMT: activation (enabled: true)

ATTENTION: PLEASE PROVIDE THE DETAILS REQUESTED BELOW.

Describe what you observed.

panic:   stmt.go:932: assertion failed

goroutine 3607 [running]:
go/types.(*Checker).handleBailout(0x1400113ca00, 0x14005649878)
      check.go:367  0x9c
panic({0x102d833a0%3F, 0x14000aee0e0%3F})
      panic.go:770  0x124
go/types.assert(0x0%3F)
      errors.go:28  0x60
go/types.(*Checker).rangeStmt(0x1400113ca00, 0x3, 0x140030696e0)
      stmt.go:932  0xb58
go/types.(*Checker).stmt(0x1400113ca00, 0x3, {0x102f0ce80, 0x140030696e0})
      stmt.go:827  0x874
go/types.(*Checker).stmtList(0x1400113ca00, 0x3, {0x140030c0480%3F, 0x102a04115%3F, 0x5%3F})
      stmt.go:121  0x88
go/types.(*Checker).stmt(0x1400113ca00, 0x3, {0x102f0ce20, 0x140030b0fc0})
      stmt.go:562  0x1974
go/types.(*Checker).rangeStmt(0x1400113ca00, 0x3, 0x14003069920)
      stmt.go:993  0x570
go/types.(*Checker).stmt(0x1400113ca00, 0x0, {0x102f0ce80, 0x14003069920})
      stmt.go:827  0x874
go/types.(*Checker).stmtList(0x1400113ca00, 0x0, {0x1400303f580%3F, 0x1020ec4e8%3F, 0x14005648668%3F})
      stmt.go:121  0x88
go/types.(*Checker).funcBody(0x1400113ca00, 0x102f0a588%3F, {0x102a364cd%3F, 0x140000d4380%3F}, 0x14002ea4600, 0x140030b1050, {0x0%3F, 0x0%3F})
      stmt.go:41  0x21c
go/types.(*Checker).exprInternal.func1()
      expr.go:1089  0x44
go/types.(*Checker).processDelayed(0x1400113ca00, 0x92)
      check.go:467  0x12c
go/types.(*Checker).stmt(0x1400113ca00, 0x0, {0x102f0cd00, 0x140030b4960})
      stmt.go:832  0x1db0
go/types.(*Checker).stmtList(0x1400113ca00, 0x0, {0x140007e5d00%3F, 0x0%3F, 0x140056496d8%3F})
      stmt.go:121  0x88
go/types.(*Checker).funcBody(0x1400113ca00, 0x102f0a588%3F, {0x140007843a0%3F, 0x140000d4380%3F}, 0x140028ff6c0, 0x140030b1080, {0x0%3F, 0x0%3F})
      stmt.go:41  0x21c
go/types.(*Checker).funcDecl.func1()
      decl.go:852  0x44
go/types.(*Checker).processDelayed(0x1400113ca00, 0x0)
      check.go:467  0x12c
go/types.(*Checker).checkFiles(0x1400113ca00, {0x14003bb7300, 0xa, 0x10})
      check.go:411  0x188
go/types.(*Checker).Files(...)
      check.go:372
golang.org/x/tools/gopls/internal/cache.(*typeCheckBatch).checkPackage(0x1400546e8a0, {0x102f0e168, 0x14003234270}, 0x14003683c20)
      check.go:1543  0x788
golang.org/x/tools/gopls/internal/cache.(*typeCheckBatch).handleSyntaxPackage(0x1400546e8a0, {0x102f0e168, 0x14003234270}, 0x0, {0x14000ab48d0, 0x2d})
      check.go:568  0x534
golang.org/x/tools/gopls/internal/cache.(*Snapshot).forEachPackageInternal.func2()
      check.go:418  0x34
golang.org/x/sync/errgroup.(*Group).Go.func1()
      errgroup.go:78  0x58
created by golang.org/x/sync/errgroup.(*Group).Go in goroutine 151
      errgroup.go:75  0x98

gopls stats -anon

{ "DirStats": { "Files": 1984, "TestdataFiles": 5, "GoFiles": 1083, "ModFiles": 1, "Dirs": 235 }, "GOARCH": "arm64", "GOOS": "darwin", "GOPACKAGESDRIVER": "", "GOPLSCACHE": "", "GoVersion": "go1.22.5", "GoplsVersion": "v0.16.1", "InitialWorkspaceLoadDuration": "1.169338542s", "MemStats": { "HeapAlloc": 60239376, "HeapInUse": 106414080, "TotalAlloc": 703540872 }, "WorkspaceStats": { "Files": { "Total": 2250, "Largest": 5748466, "Errs": 0 }, "Views": [ { "GoCommandVersion": "go1.22.5", "AllPackages": { "Packages": 742, "LargestPackage": 155, "CompiledGoFiles": 3962, "Modules": 26 }, "WorkspacePackages": { "Packages": 271, "LargestPackage": 63, "CompiledGoFiles": 1417, "Modules": 1 }, "Diagnostics": 0 } ] } }

OPTIONAL: If you would like to share more information, you can attach your complete gopls logs. NOTE: THESE MAY CONTAIN SENSITIVE INFORMATION ABOUT YOUR CODEBASE. DO NOT SHARE LOGS IF YOU ARE WORKING IN A PRIVATE REPOSITORY.

[findleyr]

@griesemer this recent panic appears to occur in logic that was recently back-ported to 1.22: https://go.dev/cl/580937.

The assertion failure is here: https://cs.opensource.google/go/go/+/refs/tags/go1.22.5:src/go/types/stmt.go;l=932;drc=11b861e45936eb7911e30304163a14553f53a5d1

assert(i == 0) // at most one iteration variable (rhs[1] == nil for rangeOverInt)

[findleyr]

@lmorg if you happen to recall any details about the range statement you were editing at the time of this panic, that would be helpful, but in any case we should be able to find the logical flaw (I'll note that this assertion was discussed in code review; we must have missed something).

@griesemer tentatively assigning to you for further investigation. I can also take a look, but will first be busy with #68311. The bug may be easy to spot--I did not attempt.

[findleyr]

Actually, I think I'll be able to get to this sooner than @griesemer.

CC @timothy-king for awareness: Tim, I'll ask you to review! :)

[lmorg]

@findleyr I can't say for 100% certain but looking at the commit times on the project I was working on, and corrolating that to the report time of this issue, I'd guess it was this one:

https://github.com/lmorg/murex/blob/37b8ce0c539eefce7c6deadb28f9bc2d51a5e39a/builtins/core/modules/cmd-list.go#L152

[lmorg]

Sorry, this one: https://github.com/lmorg/murex/blob/37b8ce0c539eefce7c6deadb28f9bc2d51a5e39a/builtins/core/modules/cmd-list.go#L95

https://github.com/lmorg/murex/pull/823/commits/37b8ce0c539eefce7c6deadb28f9bc2d51a5e39a#diff-aa1232e0202826677facafef616e8f6fc85f672ff6749e4a77cd7503e70ac33e

I cannot replicate the issue though.

[timothy-king]

edit: Nope. That wasn't it.

~gopls sets types.Config.Error to a non-nil function. If check.conf.Error != nil, then~

        case v == nil && sValue != nil:
            check.softErrorf(sValue, InvalidIterVar, "range over %s permits only one iteration variable", &x)

~won't stop execution in (*types.Checker).rangeStmt. This might be how assert(i == 0) is getting triggered.~

[gabyhelp]

Related Issues and Documentation

• x/tools/gopls: panic after failed PosRange in xrefs.Index #67704
• go/types, types2: gopls crash in recordTypeAndValue #51658 (closed)
• x/tools/gopls: crash importing test variant of tools file #66109 (closed)
• go/types, types: gopls crash in unification #50929 (closed)
• x/tools/gopls: crash when primary diagnostics have invalid positions #66731 (closed)
• x/tools/gopls: crash in goPackagesErrorDiagnostics #66875 (closed)
• go/types, types2: index out of range panic in Checker.arguments #61931 (closed)
• x/tools/gopls: automated issue report (crash) #45183 (closed)
• x/tools/gopls: crash in typeparams.Free.Has (empty type set) #68213 (closed)
• x/tools/gopls: automated issue report (crash): file not found for pos = 1 (-) #66790

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

[gopherbot]

Change https://go.dev/cl/597356 mentions this issue: go/types: fix range over int invariant

[findleyr]

@gopherbot please backport this issue to 1.22. It is a regression in the latest patch release and causes crashes in gopls.

[gopherbot]

Backport issue(s) opened: #68370 (for 1.22).

Remember to create the cherry-pick CL(s) as soon as the patch is submitted to master, according to https://go.dev/wiki/MinorReleases.

[findleyr]

Not technically a release blocker since this is already released in 1.22.5, but we should fix for 1.23 and backport.

Thanks @timothy-king for investigating.

[lmorg]

Thanks both. I appreciate there wasn't much to go on for this particular issue (sorry about that)

[findleyr]

@lmorg your time to file the issue is greatly appreciated. No need to apologize.

[gopherbot]

Change https://go.dev/cl/598055 mentions this issue: go/types: fix assertion failure when range over int is not permitted

[gopherbot]

Change https://go.dev/cl/598055 mentions this issue: [release-branch.go1.22] go/types: fix assertion failure when range over int is not permitted

[findleyr]

Closing as I believe this is fixed (in go@master). The backport issue will be closed when 1.22.6 is released.

Thanks @timothy-king for the fix.