The original need for the extra test case and issue was eliminated
by https://golang.org/cl/116815 which introduced systematic cycle
detection. Now that we correctly report the cycle, we can't say much
about the invalid cast anyway (the type is invalid due to the cycle).
A more sophisticated approach would be able to tell the size of
a function type independent of the details of that type, but the
type-checker is not set up for this kind of lazy type-checking.
Fixes #23127.
Change-Id: Ia8479e66baf630ce96f6f36770c8e1c810c59ddc
Reviewed-on: https://go-review.googlesource.com/c/141640
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Alan Donovan <adonovan@google.com>
var x3 T3
type T4 /* ERROR cycle */ interface {
- m() [unsafe.Sizeof(cast4(x4.m))]int
+ m() [unsafe.Sizeof(cast4(x4.m))]int // cast is invalid but we have a cycle, so all bets are off
}
var x4 T4
var _ = cast4(x4.m)
type cast4 func()
-
-// This test is symmetric to the T4 case: Here the cast is
-// "correct", but it doesn't work inside the T5 interface.
-
-type T5 /* ERROR cycle */ interface {
- m() [unsafe.Sizeof(cast5(x5.m))]int
-}
-
-var x5 T5
-var _ = cast5(x5.m)
-
-type cast5 func() [0]int