Comment 1:

gccgo has the same bug (issue #6684).

Comment 2:

Arguably, this is _not_ a compiler error as in general such cases cannot be detected
without more sophisticated data flow analysis. For instance, the same situation appears
in:
package p
type T struct{}
func (T) m() int { return y }
var y = f()
func f() int {
    var x interface {
        m() int
    } = T{}
    return x.m()
}
where we have a cycle but the compiler doesn't detect it. Again, in this specific case
it could, but in general, the (conservative set of) dynamic type of x inside f may not
be computable w/o some form of data flow analysis, which we are explicitly not requiring.
Thus, perhaps simply the spec needs to be clarified here (what to do when methods are
invoked).

Comment 3:

This is not a bug. It would require more work than what the spec is currently requiring
for detecting this case.
go/types also does not report this.
The spec could use clarification.

Status changed to WorkingAsIntended.

Comment 4:

The original example that reported a cycle is probably incorrect. See issue #6703 for
details.