go/types, types2: unsafe.Sizeof panics with expr of value type

[mrkfrmn]

The problem below is that during the checking of A, f is an expression that returns a B, which is not an A, but contains an A.

type A [unsafe.Sizeof(f())]int

func f() B {
	return B{}
}

type B struct {
	f A
}

[gabyhelp]

Related Issues

• go/types, types2: panic with invalid cyclic program involving unsafe.Sizeof #75918
• go/types, types2: type checker panics with unsafe.Sizeof #76384
• go/types, types2: incorrect result from unsafe.Sizeof #76383
• go/types, types2: stack overflow in hasVarSize for invalid type #48819 (closed)
• go/types, types2: array size computation may overflow to 0 #59207 (closed)
• types2: no type reported for argument to unsafe.OffsetOf #47895 (closed)
• cmd/go2go: decide what unsafe.Sizeof/Alignof mean when applied to values of type parameter type #40301 (closed)
• go/types, types2: missing error for invalid cycle in function declaration #43215
• go/types: uncommon pointer sizes result in an assertion failure #61249 (closed)
• go/types, types2: panic in type parameter->type parameter conversion #49864 (closed)

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

[cuonglm]

With the current tip, go/types and types2 seems to accept this invalid program, I think a type loop should be reported?

This is now panic during noder instead of typechecker:

$ go tool compile p.go
<unknown line number>: internal compiler error: unexpected types2.Invalid

goroutine 1 [running]:
runtime/debug.Stack()
	/home/cuonglm/sources/go/src/runtime/debug/stack.go:26 +0x5e
cmd/compile/internal/base.FatalfAt({0x45fcb380?, 0xf64?}, {0x10a4427, 0x19}, {0x0, 0x0, 0x0})
	/home/cuonglm/sources/go/src/cmd/compile/internal/base/print.go:230 +0x18c
cmd/compile/internal/base.Fatalf(...)
	/home/cuonglm/sources/go/src/cmd/compile/internal/base/print.go:195
cmd/compile/internal/noder.(*pkgWriter).typIdx(0xf6445fcb380, {0x10debb0, 0x19a5c00}, 0xf64462d1e00)
	/home/cuonglm/sources/go/src/cmd/compile/internal/noder/writer.go:530 +0x2e5
cmd/compile/internal/noder.(*writer).typ(0xf64462e5c20, {0x10debb0?, 0x19a5c00?})
	/home/cuonglm/sources/go/src/cmd/compile/internal/noder/writer.go:478 +0x2c
cmd/compile/internal/noder.(*writer).doObj(0xf64462e5c20, 0xf64462e5c70, {0x10eb0d0, 0xf64462e6720})
	/home/cuonglm/sources/go/src/cmd/compile/internal/noder/writer.go:880 +0x378
cmd/compile/internal/noder.(*pkgWriter).objIdx(...)
	/home/cuonglm/sources/go/src/cmd/compile/internal/noder/writer.go:812
cmd/compile/internal/noder.(*pkgWriter).objInstIdx(0xf6445fcb380, {0x10eb0d0, 0xf64462e6720}, 0x0, 0x0)
	/home/cuonglm/sources/go/src/cmd/compile/internal/noder/writer.go:753 +0x645
cmd/compile/internal/noder.(*writer).obj(0xf64462e5ae0, {0x10eb0d0?, 0xf64462e6720?}, 0xf6445f006b8?)
	/home/cuonglm/sources/go/src/cmd/compile/internal/noder/writer.go:727 +0x2c
cmd/compile/internal/noder.writePkgStub({0x0?, {0x0?, 0x0?}}, {0xf6445f006b8, 0x1, 0x1})
	/home/cuonglm/sources/go/src/cmd/compile/internal/noder/unified.go:342 +0x590
cmd/compile/internal/noder.unified({0x0?, {0x0?, 0x0?}}, {0xf6445f006b8?, 0xf8ea60?, 0x19aad40?})
	/home/cuonglm/sources/go/src/cmd/compile/internal/noder/unified.go:194 +0xb6
cmd/compile/internal/noder.LoadPackage({0xf6445f20070, 0x1, 0x1})
	/home/cuonglm/sources/go/src/cmd/compile/internal/noder/noder.go:77 +0x529
cmd/compile/internal/gc.Main(0x10d1dd8)
	/home/cuonglm/sources/go/src/cmd/compile/internal/gc/main.go:216 +0xd12
main.main()
	/home/cuonglm/sources/go/src/cmd/compile/main.go:57 +0x105

[mrkfrmn]

Correct — we felt it better to land CL 724140, which fixed more common cases of type loops through values even though it moved this panic to the noder.

The mechanism to efficiently discover A through B{} (and hence report the cycle) is being examined.

[gopherbot]

Change https://go.dev/cl/726580 mentions this issue: go/types, types2: add check for finite memory at value observance