R=rsc, r, ken2
CC=golang-dev
https://golang.org/cl/2128041

No semantic change.

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

What was meant to be a list appeared as a paragraph with dashes.

R=golang-dev, gri1, gri
CC=golang-dev
https://golang.org/cl/2100041

No semantic change.

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

R=gri, rsc
CC=golang-dev
https://golang.org/cl/2078041

bug255.go:11: error: array bound truncated to integer
bug255.go:12: error: array bound is not numeric
bug255.go:13: error: array bound is not numeric
bug255.go:14: error: array bound is not constant
bug255.go:15: error: array bound overflows

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

Another case where gccgo and gc report similar but not
identical errors for a recursive interface.

bug251.go:11: error: invalid recursive interface

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

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

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

This introduces GC_ERROR to mark an error only issued by the
gc compiler.  GCCGO_ERROR already exists to mark errors only
issued by the gccgo compiler.  Obviously these should be used
sparingly.

bug195.go:9: error: interface contains embedded non-interface
bug195.go:12: error: interface contains embedded non-interface
bug195.go:15: error: interface contains embedded non-interface
bug195.go:18: error: invalid recursive interface
bug195.go:22: error: invalid recursive interface

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

gcc conventionally does not upper case in error messages.

char_lit1.go:13: error: invalid unicode code point 0xd800
char_lit1.go:14: error: invalid unicode code point 0xd999
char_lit1.go:15: error: invalid unicode code point 0xdc01
char_lit1.go:16: error: invalid unicode code point 0xdddd
char_lit1.go:17: error: invalid unicode code point 0xdfff
char_lit1.go:20: error: invalid unicode code point 0x110000
char_lit1.go:22: error: invalid unicode code point 0x110000
char_lit1.go:23: error: invalid unicode code point 0xffffffff

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

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

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

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

R=r
CC=golang-dev
https://golang.org/cl/2050042

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

R=rsc, r, ken2
CC=golang-dev
https://golang.org/cl/2004046

All scripts and makefiles assume that GOBIN is correctly set
in PATH.

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

R=golang-dev, adg1, adg
CC=golang-dev
https://golang.org/cl/2075041

R=r
CC=golang-dev
https://golang.org/cl/2048043

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

See:
http://selenic.com/repo/hg/rev/32b213b9b22c
http://selenic.com/repo/hg/rev/2096496b40ec

R=rsc, adg
CC=golang-dev
https://golang.org/cl/2072041

R=golang-dev, adg
CC=golang-dev
https://golang.org/cl/2073041

(Fixes missing tags, extra tags, missing attributes, and such found by tidy -e)

R=golang-dev, adg1, adg
CC=golang-dev
https://golang.org/cl/2039043

Fixes #1056.

R=golang-dev, adg1
CC=golang-dev
https://golang.org/cl/2033043

	Not a bug per-se, the issue is that the fmt.Sprintf method inside the
	ByteSize.String() method ends up calling itself to generate the String
	representation of the ByteSize value.  Infinite loops are bad.

    Updated as per review comments

R=r
CC=golang-dev
https://golang.org/cl/1974046

Rewrite the code to express the intention more clearly.

Fixes #1042.

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

R=gri
CC=James Fysh, golang-dev
https://golang.org/cl/2043042

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

Fixes #1052.

R=ken2
CC=golang-dev
https://golang.org/cl/2055041

Fixes #1044.

R=gri
CC=golang-dev
https://golang.org/cl/1958047

R=rsc, r2
CC=golang-dev
https://golang.org/cl/2041041

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

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

R=iant
CC=golang-dev
https://golang.org/cl/2033041

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

Cuts time to upload trivial 160-file CL by 5x,
from 250 seconds to 50 seconds.

R=r
CC=golang-dev
https://golang.org/cl/1991047

a b: c expands to multiple rules,
which then run in parallel.

R=r, iant
CC=golang-dev
https://golang.org/cl/2007047

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

Two tests start a goroutine which runs exportSend, and then
the tests run importReceive.  exportSend creates an export
channel.  importReceive asks to receive values on that
channel.  Because exportSend runs in a separate goroutine,
it's possible for the export client to receive the request for
values on the channel, from importReceive, before the
goroutine actually creates the export channel.  That causes an
error: "export: no such channel: exportedSend".  This patch
avoids the race by creating the export channel before starting
the goroutine.

There does not seem to be a similar race condition in the
tests which send data in the other direction.

R=r
CC=golang-dev
https://golang.org/cl/2026045