commit c1d44c9453506cdf5725a392aa03d9aa5df580af [browse]
Author: Andrew Gerrand
Date: 2011-03-07 13:55:22 +11:00

release.2011-03-07

R=r, rsc, dfc
CC=golang-dev
https://golang.org/cl/4240081

commit 2b4a9603d33308ac8a13700dbb9489de115bd2ec [browse]
Author: Russ Cox
Date: 2011-03-06 21:52:37 -05:00

io/ioutil: use filepath.Join, handle trailing / in $TMPDIR

R=niemeyer
CC=golang-dev
https://golang.org/cl/4256057

commit 94401f524ea26f72afcb6454b0cd2c5c7749a7f5 [browse]
Author: Alex Brainman
Date: 2011-03-07 12:23:57 +11:00

path/filepath: disable test on windows to fix build

R=golang-dev, rsc1
CC=golang-dev
https://golang.org/cl/4235054

commit 6193e0ba0075963de35e35a384c2c6ce77968c67 [browse]
Author: Brad Fitzpatrick
Date: 2011-03-06 15:12:03 -08:00

mime/multipart: switch from map to MIMEHeader

R=rsc
CC=golang-dev
https://golang.org/cl/4253058

commit 99686ec789f7eacaad6d30e39243759c00035685 [browse]
Author: Gustavo Niemeyer
Date: 2011-03-06 18:05:57 -05:00

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
https://golang.org/cl/4244052