go/types: correctly compute cycle length
The existing algorithm assumed that the length of a cycle was simply the number of elements in the cycle slice starting at the start object. However, we use a special "indir" indirection object to indicate pointer and other indirections that break the inline placement of types in composite types. These indirection objects don't exist as true named type objects, so don't count them anymore. This removes an unnecessary cycle error in one of the existing tests (testdata/issues.src:100). Also: - added more tracing support (only active if tracing is enabled) - better documentation in parts - r/check.typ/check.typExpr/ in a few of places where we don't need to record a type indirection Found while investigating #26124. Change-Id: I45341743225d979a72af3fbecfa05012b32fab67 Reviewed-on: https://go-review.googlesource.com/121755 Run-TryBot: Robert Griesemer <gri@golang.org> Reviewed-by: Alan Donovan <adonovan@google.com>
Showing
Please register or sign in to comment