cmd/compile: infinite recursion generating symbol for recursive type

[gopherbot]

by lcampbell@ironclad.mobi:

1. What is a short input program that triggers the error?

package test

type Foo interface {
       Bar() *interface{Foo}
       Baz() *interface{Foo}
       Bug() *interface{Foo}
}

2. What is the full compiler output?

It seems to exhaust system memory before outputting anything. Once I was able to get it
to output

Compile error:
/Users/lcampbell/Projects/asset-tracker/app/mobi.ironclad/aec/interfaces.go:34: internal
compiler error: missing PTR64 case during export

2011/06/02 20:10:26 go-app-builder: Failed building app: 6g exited with status 1

But I am unable to reproduce it effectively.

3. What version of the compiler are you using?  (Run it with the -V flag.)

$ 6g -V
6g version release.r57.1 8294

$ uname -a
Darwin fffffuuuuuuuuuuuu 10.7.0 Darwin Kernel Version 10.7.0: Sat Jan 29 15:17:16 PST
2011; root:xnu-1504.9.37~1/RELEASE_I386 i386

[adg]

Comment 1:

Labels changed: added priority-medium, compilerbug.

Owner changed to @rsc.

Status changed to Accepted.

[lvdlvd]

Comment 2:

Owner changed to @lvdlvd.

[rsc]

Comment 3:

Labels changed: added priority-later, removed priority-medium.

[rsc]

Comment 4:

Labels changed: added priority-go1.

[gopherbot]

Comment 5 by lstoakes:

I think this underlines a more serious problem which is that code like:-
type Foo interface {
    Bar() interface { Foo }
}
Compiles without error which seems to me to be an invalid recursive type (unless I'm
missing something here). I am happy to submit a new issue for this (with reproducing
code - you get nonsensical syntax errors regarding the < of '<...>' when trying
to import a package with such a type in, for example).
src/cmd/gc/fmt.c:1453 has a mechanism for detecting + dealing with overly deep recursive
types when dumping output, i.e.:-
    if(t->trecur > 4)
        return fmtstrcpy(fp, "<...>");
However, a small increase in the number of functions within an interface which exhibits
this recursive behaviour seems to result in exponentially increasing size of the output
type (as inserted at the start of the  .6/.8/.? file).
This also varies with the limit put on t->trecur, e.g.:-
> 0 -> https://gist.github.com/1552355, 69 lines
> 1 -> https://gist.github.com/1552361, 1089 lines
> 2 -> https://gist.github.com/1552363  20,997 lines
I have submitted a trivial patch which puts a limit on the nfmt field of fp to a
somewhat arbitrary limit, which fixes the issue with the compiler going down the garden
path, but obviously not whether it identifies this situation as invalid recursion:-
http://golang.org/cl/5504108/

[lvdlvd]

Comment 6:

Status changed to Started.

[lvdlvd]

Comment 7:

The underlying problem is that embedded interfaces are substituted by their methods
early on, and then the original embedded field is lost.  I started by making
tointerface() retain the originals, and mark them and their imported methods as
->embedded.  then typefmt can print skip the embedded methods and print the interface
they came from (possibly only for recursive types).   This involves skipping over the
now-retained TINTER fields in some places and making go.y accept them too.  
Since it's nearly weekend and there's no rsc to bounce this off off, i thought i'd write
it up here.
work in progress in http://golang.org/cl/5523047

[rsc]

Comment 8:

This issue was closed by revision aa63a92.

Status changed to Fixed.

[rsc]

Comment 9:

This is not actually fixed, but the CL does make it a little less crashy.

Status changed to Accepted.

[lvdlvd]

Comment 10:

i'm in the middle of a real fix, marking 'started' to prevent duplicate effort

Status changed to Started.

[rsc]

Comment 11:

This issue was closed by revision 8a4bd09.

Status changed to Fixed.

[lvdlvd]

Comment 12:

that revision was a rollback.

Status changed to Started.

[lvdlvd]

Comment 13:

Pending in http://golang.org/cl/5523047/, but that still needs a fix to
exp/types/gcimporter.

[robpike]

Comment 14:

Owner changed to builder@golang.org.

[rsc]

Comment 15:

Owner changed to @lvdlvd.