cmd/compile: type checking fails in cycle involving recursive struct and unsafe.Sizeof

[rsc]

package p

import "unsafe"

type hdr struct {
    next *msg
}

type msg struct {
    hdr
    pad [1024-hdrsize]uint8
}

const hdrsize = unsafe.Sizeof(hdr{})

This should type check but does not:

$ go tool compile /tmp/x.go
/tmp/x.go:14: invalid type for composite literal: hdr
/tmp/x.go:14: invalid expression unsafe.Sizeof(hdr literal)

Looks like the compiler gets confused by the not-quite-cycle in the definition.

http://play.golang.org/p/Hbmv1j_UrR

/cc @RLH

[davmaz]

Could this also be the case (when using cgo):
phySize := unsafe.Sizeof(C.struct_ad9361_rf_phy)
giving a compile time error:
invalid expression unsafe.Sizeof(_Ctype_struct_ad9361_rf_phy)

[ianlancetaylor]

@davmaz No, the problem there is simply that unsafe.Sizeof takes a value, not a type. It's not the same as the C sizeof operation.

In general, for the Go project, please ask questions in a forum rather than on the issue tracker. See https://golang.org/wiki/Questions. Thanks.

[mdempsky]

The problem is that when typechecking a pointer to a named type like *msg, cmd/compile recurses and tries to completely typecheck msg. Instead, we should just do the minimum to get a *Type value for msg (in this case a TFORW type) so we can construct the *msg pointer type. Later when we visit msg's type declaration, we can finish typechecking it.

A workaround is to move the hdr type declaration after the msg type declaration.

[rsc]

Quite possibly Robert's front end revamp will take care of this. Maybe not worth worrying about before then.

[griesemer]

FWIW, gotype accepts this code w/o problems. Since there's a work-around per @mdempsky I don't think there's any urgency here.

[josharian]

Reproduced at tip (00263a8) on May 10, 2017.

Still seems low priority; punting to 1.10.