Fixes #5315.

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

I read docs and wrote a crawler + link checker on the plane,
which also checks for #fragments. I'll send that out later
when it's less gross.

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

https://golang.org/cl/8134043 disabled cgo when cross compiling, this means builders which compile for both amd64 and 386 will be compiling the latter with cgo disabled.

This proposal modifies the builder to mirror the dist tool by always doing a native build.

Tested on my darwin/amd64 builder and confirmed the result when building darwin/386 is a native 386 build with cgo enabled.

R=bradfitz, dsymonds, r, adg
CC=golang-dev
https://golang.org/cl/8842044

Also document the panic to be consistent with math/rand.

Fixes #5187.

R=golang-dev, dave, bradfitz, r
CC=golang-dev
https://golang.org/cl/8303043

Late bug fix, but this is arguably a regression from Go 1.0,
since we added this transparent decoding since then. Without
this fix, Go 1.0 users could decode this correctly, but Go 1.1
users would not be able to.

The newly added test is from the RFC itself.

The updated tests had the wrong "want" values before. They
were there to test \r\n vs \n equivalence (which is
unchanged), not leading whitespace.

The skipWhite decoder struct field was added in the battles of
Issue 4771 in revision b3bb265bfecf. It was just a wrong
strategy, from an earlier round of attempts in
https://golang.org/cl/7300092/

Update #4771
Fixes #5295

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

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

Fixes #5293

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

Fixes #5307

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

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

See https://code.google.com/p/go/issues/detail?id=5227#c16.

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

I wrote a tool.

R=golang-dev, bradfitz
CC=golang-dev
https://golang.org/cl/8695047

It's clear that that should never happen.

R=golang-dev, bradfitz
CC=golang-dev
https://golang.org/cl/8798045

Fixes #5296.

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

Fixes #5261.

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

Update #4979.

R=dvyukov, r, bradfitz
CC=golang-dev
https://golang.org/cl/8697045

From the issue, which describes it as well as I could:

database/sql assumes that driver.Stmt.Close does not need the
connection.

see database/sql/sql.go:1308:

This puts the Rows' connection back into the idle pool, and
then calls the driver.Stmt.Close method of the Stmt it belongs
to.  In the postgresql driver implementation
(https://github.com/lib/pq), Stmt.Close communicates with the
server (on the connection that was just put back into the idle
pool).  Most of the time, this causes no problems, but if
another goroutine makes a query at the right (wrong?) time,
chaos results.

In any case, traffic is being sent on "free" connections
shortly after they are freed, leading to race conditions that
kill the driver code.

Fixes #5283

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

R=golang-dev, bradfitz, r
CC=golang-dev
https://golang.org/cl/8766043

R=golang-dev, r, gary.burd, dr.volker.dobler
CC=golang-dev
https://golang.org/cl/8660046

Runs forever, stressing the runtime in various ways.

It should never terminate.

R=golang-dev, r, minux.ma
CC=golang-dev
https://golang.org/cl/8583047

Update #5106
Update #5273

R=minux.ma, r
CC=golang-dev
https://golang.org/cl/8715043

R=golang-dev, minux.ma, r
CC=golang-dev
https://golang.org/cl/8569043

R=golang-dev, dsymonds, r
CC=golang-dev
https://golang.org/cl/8592044

R=golang-dev, dsymonds
CC=golang-dev
https://golang.org/cl/8729045

They caused internal compiler errors and they're expensive enough that inlining them doesn't make sense.

Fixes #5259.

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

For compliance with gc. See also issue 5265.
Not Go1.1 critical, but harmless.

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

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

Update #5281

R=golang-dev, r, bradfitz, cshapiro
CC=golang-dev
https://golang.org/cl/8631047

Updates #5282

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

Debug output from go test -x may contain empty arguments.
This CL quotes arguments if needed. E.g. the output of
go test -x is now
  .../6g -o ./_go_.6 -p testmain -complete -D "" -I . -I $WORK ./_testmain.go
which is easier to grasp.

R=golang-dev, bradfitz, minux.ma, r
CC=golang-dev
https://golang.org/cl/8633043

Debug output from go test -x may contain empty arguments.
This CL quotes arguments if needed. E.g. the output of
go test -x is now
  .../6g -o ./_go_.6 -p testmain -complete -D "" -I . -I $WORK ./_testmain.go
which is easier to grasp.

R=golang-dev, bradfitz, minux.ma, r
CC=golang-dev
https://golang.org/cl/8633043

There are tests in run.bash for -linkmode=external.

Fixes #5238.

R=golang-dev, bradfitz, remyoudompheng, r
CC=golang-dev
https://golang.org/cl/8716044

R=golang-dev, minux.ma, r
CC=golang-dev
https://golang.org/cl/8709043

This will let us ask people to rebuild the Go system without
precise GC, and then rebuild and retest their program, to see
if precise GC is causing whatever problem they are having.

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

UMTX_OP_WAIT expects that the address points to a uintptr, but
the code in lock_futex.c uses a uint32.  UMTX_OP_WAIT_UINT is
just like UMTX_OP_WAIT, but the address points to a uint32.
This almost certainly makes no difference on a little-endian
system, but since the kernel supports it we should do the
right thing.  And, who knows, maybe it matters.

R=golang-dev, bradfitz, r, ality
CC=golang-dev
https://golang.org/cl/8699043

Fixes #5258.

R=golang-dev, iant, minux.ma
CC=golang-dev
https://golang.org/cl/8682043

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

Fixes #5260.

R=golang-dev, minux.ma, 0xjnml, r
CC=golang-dev
https://golang.org/cl/8658043

Although one may argue that they should be legal, gc (at least)
disallows byte order marks that are not the first code point
in the file. Added a sentence to the "Implementation restriction"
clause in the "Source code representation" section to document
this better.

Lifting this restriction (again - the rule has changed at least
twice already) would not break any existing programs, should
we later decide yet again to fiddle the rules about these little
fly specks.

R=golang-dev, dsymonds, gri
CC=golang-dev
https://golang.org/cl/8649043

This change removes processing of #cgo directives from cmd/cgo,
pushing the onus back on cmd/go to pass all necessary flags.

Fixes #5224. See comments for rationale.

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

Fixes #5268.

R=golang-dev, dsymonds, bradfitz
CC=golang-dev
https://golang.org/cl/8646045