go/types: incorrect "no such field/method" error in cyclic interface

[alandonovan]

The following excerpt minimized from a real program causes go/types to emit a spurious error:

$ cat a.go
package base

type A interface {
        B
}

type B interface {
        C
}

type C interface {
        D
        F() A
}

type D interface {
        G() B
}

var _ = A(nil).G // error: no such field or method
$ ssadump a.go
a.go:20:9: invalid operation: A(nil) (value of type A) has no field or method G
ssadump: couldn't load packages due to errors: base

[griesemer]

Nice. It appears that the existing algorithm for type-checking interfaces is incorrect, and this subtle example exposes the problem. Type-checking proceeds as follows:

$ gotype y.go
y.go:16:6:	-- declaring D
y.go:16:8:	.  interface{G() B}
y.go:17:10:	.  .  func() B
y.go:17:13:	.  .  .  B
y.go:7:6:	.  .  .  .  -- declaring B
y.go:7:8:	.  .  .  .  .  interface{C}
y.go:8:9:	.  .  .  .  .  .  C
y.go:11:6:	.  .  .  .  .  .  .  -- declaring C
y.go:11:8:	.  .  .  .  .  .  .  .  interface{D; F() A}
y.go:12:9:	.  .  .  .  .  .  .  .  .  D
y.go:12:9:	.  .  .  .  .  .  .  .  .  => D
y.go:13:10:	.  .  .  .  .  .  .  .  .  func() A
y.go:13:13:	.  .  .  .  .  .  .  .  .  .  A
y.go:3:6:	.  .  .  .  .  .  .  .  .  .  .  -- declaring A
y.go:3:8:	.  .  .  .  .  .  .  .  .  .  .  .  interface{B}
y.go:4:9:	.  .  .  .  .  .  .  .  .  .  .  .  .  B
y.go:4:9:	.  .  .  .  .  .  .  .  .  .  .  .  .  => B
y.go:3:8:	.  .  .  .  .  .  .  .  .  .  .  .  => interface{B}
y.go:3:6:	.  .  .  .  .  .  .  .  .  .  .  => type A interface{B}
y.go:13:13:	.  .  .  .  .  .  .  .  .  .  => A
y.go:13:10:	.  .  .  .  .  .  .  .  .  => func() A
y.go:11:8:	.  .  .  .  .  .  .  .  => interface{F() A; D}
y.go:11:6:	.  .  .  .  .  .  .  => type C interface{F() A; D}
y.go:8:9:	.  .  .  .  .  .  => C
y.go:7:8:	.  .  .  .  .  => interface{C}
y.go:7:6:	.  .  .  .  => type B interface{C}
y.go:17:13:	.  .  .  => B
y.go:17:10:	.  .  => func() B
y.go:16:8:	.  => interface{G() B}
y.go:16:6:	=> type D interface{G() B}
y.go:20:5:	-- declaring _
y.go:20:9:	.  A(nil).F
y.go:20:9:	.  .  A(nil)
y.go:20:9:	.  .  .  A
y.go:20:9:	.  .  .  => A (type)
y.go:20:11:	.  .  .  nil
y.go:20:11:	.  .  .  => nil (untyped nil value)
y.go:20:9:	.  .  => A(nil) (value of type A)
y.go:20:9: invalid operation: A(nil) (value of type A) has no field or method F
y.go:20:9:	.  => A(nil).F (invalid operand)
y.go:20:5:	=> var _ invalid type

The problem is that the collection of methods for method A depends on B at a time when interface B is not yet finished collecting its methods.

A correct (?) approach may require the collection of all methods first, for all interfaces, before proceeding with type-checking their signatures. This may also eliminate the need for a topological sort of the interfaces before type-checking them (see ordering.go, Checker.resolveOrder). Either way, a correct solution requires some serious thinking.

This is too invasive a change for Go1.9. Postponing to 1.10.

[gopherbot]

Change https://golang.org/cl/78955 mentions this issue: go/types: add debugging code to detect use of incomplete interfaces

[griesemer]

Status update: Started working on this. Have a basic solution based on proposed solution above (collecting methods first, before creating the respective types). Working on cleaning up the approach (it's a lot of code).

[rsc]

If it's a lot of code maybe this should wait for Go 1.11?

[griesemer]

@rsc: Maybe. The issue is that not having this will prevent vet from working in some cases. They are rare but so far three have been filed. I want to work on this just a tad longer to see what the final outcome is.

[gopherbot]

Change https://golang.org/cl/79575 mentions this issue: go/types: correctly compute method set of some recusive interfaces

[griesemer]

Decided to postpone submit of fix to 1.11 in discussion with @rsc, @ianlancetaylor . See also related #22890.

[gopherbot]

Change https://golang.org/cl/80455 mentions this issue: go/types: panic when recognizing issue #18395.

[gopherbot]

Change https://golang.org/cl/84898 mentions this issue: go/types: perform delayed tests even for types.Eval

[gopherbot]

Change https://golang.org/cl/108555 mentions this issue: cmd/go: respect vet typecheck failures again