go/types: report `invalid recursive type` on valid code

[wdvxdr1123]

Go version

gotip

Output of go env in your module/workspace:

.

What did you do?

package main

import (
	"unsafe"
)

type F interface {
	A() V
}

const size = unsafe.Sizeof(F(nil))

type V struct {
	_ [size]int
}

func main() {
	_ = V{}
}

https://go.dev/play/p/PTaVuR0dIyw?v=gotip

What did you see happen?

./prog.go:8:6: invalid recursive type F
	./prog.go:8:6: F refers to V
	./prog.go:14:6: V refers to size
	./prog.go:12:7: size refers to F

What did you expect to see?

compile pass
This issue does not exist on go1.25.
cc @griesemer @mrkfrmn

[gabyhelp]

Related Issues

• go/types: specious "invalid recursive type" error? #60130
• cmd/compile: valid go1.17 non-recursive program fails to compile with invalid recursive type error #59437 (closed)
• go/types, cmd/compile: "invalid type loop" depending on declaration order #51244
• cmd/compile: spurious invalid recursive type #57176 (closed)
• "Invalid recursive type" error for non-recursive types #582 (closed)
• go/types: recursive type aliases might cause a panic #71284 (closed)
• go/types: accepts invalid `type T = interface{ f(T) }` #23139 (closed)
• cmd/compile: type checking fails in cycle involving recursive struct and unsafe.Sizeof #14620
• cmd/compile: spurious "invalid recursive type" error in anonymous, recursive interfaces #56062 (closed)
• go/types, types2: missing error for invalid cycle in function declaration #43215

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

[mrkfrmn]

Here's a more minimal reproducer:

type I interface {
	m() A
}

type A [unsafe.Sizeof(I(nil))]int

The issue is that I(nil) "produces" a value of type I while I is under construction; in this case, the Go compiler reports a cycle error. This is discussed at length here.

Is there a use case that requires you to size an interface like so?

[wdvxdr1123]

@mrkfrmn we use to calculate the cache line pad size, like

type A struct {
    foo    X
    _      [CacheLinePadSize - unsafe.Sizeof(X(nil))]byte
    ...
}

[mrkfrmn]

Got it — FWIW I think if X is an interface type, it will always be 2 words regardless of the structure of the interface.

[griesemer]

@mrkfrmn Do we not break the cycle when we need the unsafe.Sizeof of a type that has a known size even when not fully constructed yet? If not, can we easily do it?

[ianlancetaylor]

I think the right question here is: what does the spec say? I don't see anything about unsafe.Sizeof in https://go.dev/ref/spec#Package_initialization, so it seems to me that go/types is correctly reporting an error for this program.

[mrkfrmn]

@griesemer we do for composite types, but not declared types.

We push the analysis upstream to X(nil) above; as soon as we see that the expression will produce exactly an X and X has incomplete type internals, we report a cycle error—unsafe.Sizeof only sees Invalid. Otherwise, the type checker needs to know how to handle incomplete values, which seems tricky.

However, if it were new(X), then we haven't produced an X, but rather a *X, which we can size. We can size most composite types referring to X, but not X directly.

So just to illustrate, type A [unsafe.Sizeof(interface { m() A }(nil))]int is fine, but type A [unsafe.Sizeof(I(nil)]int isn't.

[griesemer]

@ianlancetaylor We actually say almost nothing about cycles in the spec. Perhaps we can say that all interfaces have a fixed constant size, which is implementation specific and not further specified, and which doesn't depend on the interface's composition. Same is true for pointers and functions. This would allow programs to compute these as needed. It would allow this code.