Closed thaJeztah closed 1 month ago
Running tests on go1.22 or up resulted in a panic. After testing new versions of the module, it looks like v0.13.0 is the lowest version that fixes this issue. I was not able to find the fix, but this is the diff between 0.12 and 0.13;
=== FAIL: assert/cmd/gty-migrate-from-testify TestRun (unknown) panic: runtime error: invalid memory address or nil pointer dereference [recovered] panic: runtime error: invalid memory address or nil pointer dereference [signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x69b46f] goroutine 26 [running]: go/types.(*Checker).handleBailout(0xc0001ec400, 0xc00056bc10) /usr/local/go/src/go/types/check.go:367 +0x88 panic({0x7e1600?, 0xb549e0?}) /usr/local/go/src/runtime/panic.go:770 +0x132 go/types.(*StdSizes).Sizeof(0x0, {0x8f2298, 0xb597a0}) /usr/local/go/src/go/types/sizes.go:228 +0x30f go/types.(*Config).sizeof(...) /usr/local/go/src/go/types/sizes.go:333 go/types.representableConst.func1({0x8f2298?, 0xb597a0?}) /usr/local/go/src/go/types/const.go:76 +0x9e go/types.representableConst({0x8f46a8, 0xb4c080}, 0xc0001ec400, 0xb597a0, 0xc00056a828) /usr/local/go/src/go/types/const.go:92 +0x192 go/types.(*Checker).representation(0xc0001ec400, 0xc0000cd340, 0xb597a0) /usr/local/go/src/go/types/const.go:256 +0x65 go/types.(*Checker).implicitTypeAndValue(0xc0001ec400, 0xc0000cd340, {0x8f2298, 0xb597a0}) /usr/local/go/src/go/types/expr.go:375 +0x2d7 go/types.(*Checker).assignment(0xc0001ec400, 0xc0000cd340, {0x8f2298, 0xb597a0}, {0x8562d9, 0x10}) /usr/local/go/src/go/types/assignments.go:52 +0x2e5 go/types.(*Checker).initVar(0xc0001ec400, 0xc00080cea0, 0xc0000cd340, {0x8562d9, 0x10}) /usr/local/go/src/go/types/assignments.go:163 +0x3b2 go/types.(*Checker).initVars(0xc0001ec400, {0xc00029c0e0, 0x1, 0xc000182778?}, {0xc0006400b0, 0xc00019cd98?, 0x5ca910480cf0dcad?}, {0x8f3b60, 0xc000648680}) /usr/local/go/src/go/types/assignments.go:382 +0x638 go/types.(*Checker).stmt(0xc0001ec400, 0x0, {0x8f3b60, 0xc000648680}) /usr/local/go/src/go/types/stmt.go:524 +0x1fc5 go/types.(*Checker).stmtList(0xc0001ec400, 0x0, {0xc0006400c0?, 0x0?, 0x0?}) /usr/local/go/src/go/types/stmt.go:121 +0x85 go/types.(*Checker).funcBody(0xc0001ec400, 0x8f2298?, {0xc00060c1e4?, 0xb597a0?}, 0xc0000cd2c0, 0xc00064c600, {0x0?, 0x0?}) /usr/local/go/src/go/types/stmt.go:41 +0x331 go/types.(*Checker).funcDecl.func1() /usr/local/go/src/go/types/decl.go:852 +0x3a go/types.(*Checker).processDelayed(0xc0001ec400, 0x0) /usr/local/go/src/go/types/check.go:467 +0x162 go/types.(*Checker).checkFiles(0xc0001ec400, {0xc000286140, 0x2, 0x2}) /usr/local/go/src/go/types/check.go:411 +0x1cc go/types.(*Checker).Files(...) /usr/local/go/src/go/types/check.go:372 golang.org/x/tools/go/packages.(*loader).loadPackage(0xc0001fc700, 0xc0004de330) /go/pkg/mod/golang.org/x/tools@v0.3.0/go/packages/packages.go:1037 +0x932 golang.org/x/tools/go/packages.(*loader).loadRecursive.func1() /go/pkg/mod/golang.org/x/tools@v0.3.0/go/packages/packages.go:847 +0x1a9 sync.(*Once).doSlow(0x0?, 0x0?) /usr/local/go/src/sync/once.go:74 +0xc2 sync.(*Once).Do(...) /usr/local/go/src/sync/once.go:65 golang.org/x/tools/go/packages.(*loader).loadRecursive(0x0?, 0x0?) /go/pkg/mod/golang.org/x/tools@v0.3.0/go/packages/packages.go:835 +0x4a golang.org/x/tools/go/packages.(*loader).loadRecursive.func1.1(0x0?) /go/pkg/mod/golang.org/x/tools@v0.3.0/go/packages/packages.go:842 +0x26 created by golang.org/x/tools/go/packages.(*loader).loadRecursive.func1 in goroutine 24 /go/pkg/mod/golang.org/x/tools@v0.3.0/go/packages/packages.go:841 +0x94 DONE 280 tests, 1 skipped, 1 failure in 35.246s
@dnephin @vdemeester PTAL 🤗
thaJeztah
commented
1 month ago
Running tests on go1.22 or up resulted in a panic. After testing new versions of the module, it looks like v0.13.0 is the lowest version that fixes this issue. I was not able to find the fix, but this is the diff between 0.12 and 0.13;