code review 4244052: cgo: fix dwarf type parsing

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.

[niemeyer, 2011-03-06 13:45:19]

Hello rsc (cc: golang-dev@googlegroups.com),

I'd like you to review this change to
https://go.googlecode.com/hg/

[rsc, 2011-03-06 22:37:32]

LGTM

http://codereview.appspot.com/4244052/diff/6001/src/cmd/cgo/gcc.go
File src/cmd/cgo/gcc.go (right):

http://codereview.appspot.com/4244052/diff/6001/src/cmd/cgo/gcc.go#newcode789
src/cmd/cgo/gcc.go:789: return fmt.Sprintf(tr.Repr, tr.FormatArgs...)
Very cool.

[rsc, 2011-03-06 23:06:02]

*** Submitted as http://code.google.com/p/go/source/detail?r=7c7d23f8ddbc ***

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>