cgo: fix dwarf type parsing

The recursive algorithm used to parse types in cgo
has a bug related to building the C type representation.

As an example, when the recursion starts at a type *T,
the C type representation won't be known until type T
itself is parsed.  But then, it is possible that type T
references the type **T internally.  The latter
representation is built based on the one of *T, which
started the recursion, so it won't attempt to parse it
again, and will instead use the current representation
value for *T, which is still empty at this point.

This problem was fixed by introducing a simple TypeRepr
type which builds the string representation lazily,
analogous to how the Go type information is built within
the same algorithm.  This way, even if a type
representation is still unknown at some level in the
recursion, representations dependant on it can still
be created correctly.

R=rsc
CC=golang-dev
http://codereview.appspot.com/4244052

Committer: Russ Cox <rsc@golang.org>

1 files changed, 7 insertions, 1 deletions

diff --git a/src/cmd/cgo/main.go b/src/cmd/cgo/main.go
index dbf0664dc..2dc662de5 100644
--- a/src/cmd/cgo/main.go
+++ b/src/cmd/cgo/main.go
@@ -82,11 +82,17 @@ type ExpFunc struct {
 	ExpName string // name to use from C
 }
 
+// A TypeRepr contains the string representation of a type.
+type TypeRepr struct {
+	Repr       string
+	FormatArgs []interface{}
+}
+
 // A Type collects information about a type in both the C and Go worlds.
 type Type struct {
 	Size       int64
 	Align      int64
-	C          string
+	C          *TypeRepr
 	Go         ast.Expr
 	EnumValues map[string]int64
 }