cmd/compile: interface definition cannot contain itself inside an anonymous interface method argument

[juamedgod]

Please answer these questions before submitting your issue. Thanks!

1. What version of Go are you using (go version)?

go1.6.2

1. What operating system and processor architecture are you using (go env)?

GOARCH="amd64"
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"

1. What did you do?

I tried to define an interface that expects itself as the argument of one of its methods:

type Nestable interface {
   AddChild(interface{Nestable})
}

https://play.golang.org/p/oB091DHIS2

1. What did you expect to see?

I would expect it to simply look for the desired signature of the argument passed in and accept it as valid

1. What did you see instead?

It seems it recursively walk the full interface definition so it enters som kind of loop

panic: interface conversion: *main.TreeNode is not interface { AddChild(interface { AddChild(interface { AddChild(interface { AddChild(interface { AddChild(interface { AddChild<...> }) }) }) }) }) }: missing method AddChild

[mvdan]

Error on tip (go version devel +fc80387 Mon Jul 11 21:03:09 2016 +0000 linux/amd64) is different:

runtime: goroutine stack exceeds 1000000000-byte limit
fatal error: stack overflow

runtime stack:
runtime.throw(0x8f8c67, 0xe)
        /home/mvdan/tip/src/runtime/panic.go:566 +0x95
runtime.newstack()
        /home/mvdan/tip/src/runtime/stack.go:1061 +0x416
runtime.morestack()
        /home/mvdan/tip/src/runtime/asm_amd64.s:366 +0x7f

goroutine 1 [running]:
encoding/binary.PutVarint(0xc440484316, 0xa, 0xa, 0xfffffffffffffff2, 0x0)
        /home/mvdan/tip/src/encoding/binary/varint.go:78 fp=0xc4404842d8 sp=0xc4404842d0
cmd/compile/internal/gc.(*exporter).rawInt64(0xc460483890, 0xfffffffffffffff2)
        /home/mvdan/tip/src/cmd/compile/internal/gc/bexport.go:1712 +0x5d fp=0xc440484330 sp=0xc4404842d8
[...]

[josharian]

Not a regression from 1.6, so I'm marking as 1.8.

[ianlancetaylor]

Are you sure it's not a regression? It seems to compile for me with 1.6.

[josharian]

Hmm. It fails at run time on 1.6, but compile time at tip. Not sure whether that counts as a regression or not.

[ianlancetaylor]

Oh, I see. I agree: not a regression.

The test case seems to work with gccgo.

[griesemer]

The new importer/exporter can handle this data structure w/o problem but we had to turn off the mechanism a while back because the compiler's internal type representation cannot handle such a recursive type (see trackAllTypes flag in bexport.go of the compiler). Unfortunately this broke cycle detection and we get a stack overflow.

This should probably report an error, or perhaps silently pass as was the case with 1.6.

Note also while this "seems to work" with 1.6, the compiler actually cannot import the resulting package anymore (syntax error in import). Any package with such an interface-recursive exported type cannot be imported - it's only useful at the top-level (main package), but in that case such a type doesn't need to be exported.

With 1.6, for:

package main

type T interface {
    M(interface {
        T
    })
}

the export data looks like:

$$
package main
    type @"".T interface { M(? interface { M(? interface { M(? interface { M(? interface { M(? interface { M<...> }) }) }) }) }) }
    func @"".init ()

$$

(Note the recursion that's "terminated" with interface { M<...> } which cannot be parsed by the importer.)

Probably not a release blocker, but I'll see if there's a low-risk fix that could prevent the crash.

[griesemer]

PS: The reason the compiler cannot handle this type is that it "flattens" interface types: interface{T} becomes an anonymous interface with the method M of T and when exported, we have cycle that doesn't use a named type. The compiler's data structures cannot handle such types when read in.

[gopherbot]

CL https://golang.org/cl/24979 mentions this issue.

[rsc]

Currently:

$ go run /tmp/x.go
# command-line-arguments
/tmp/x.go:5: cannot export unnamed recursive interface
$ 

That's at least very clear.

[gopherbot]

CL https://golang.org/cl/38392 mentions this issue.

[gopherbot]

CL https://golang.org/cl/38391 mentions this issue.

[gopherbot]

CL https://golang.org/cl/38490 mentions this issue.