Now that revision 0c029965805f is in, it's easy
to guarantee that we never access a driver.Conn
concurrently, per the database/sql/driver contract,
so we can remove this overlarge mutex.

Fixes #3857

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

If LookPath in Command fails, sets a sticky error, and then
StdinPipe, StdoutPipe, or StderrPipe were called, those pipe
fds were never cleaned up.

Fixes #5071

R=golang-dev, rogpeppe
CC=golang-dev
https://golang.org/cl/7799046

The current SysAlloc implementation suffers from a signed vs unsigned
comparision bug. Since the error code from mmap is negated, the
unsigned comparision of v < 4096 is always false on error. Fix this
by switching to the darwin/freebsd/linux mmap model and leave the mmap
return value unmodified.

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

The files could use some attention on the
Windows side but better to wait until after
the upcoming release.

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

Update #4501.

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

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

Avoids printing it every time we ask a question about the package from
the command line.

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

Too annoying and flaky to debug for now. Later. This
tangent has taken enough time.

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

Fixes #5014.

R=golang-dev, r, rsc, daniel.morsing
CC=golang-dev
https://golang.org/cl/7664043

Treat the Windows net server as uninteresting for leak
purposes too.

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

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

Fixes #5005

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

The rule is not concistently followed by gc.
It appears that gccgo is ignoring it. go/types
does not implement this rule. However, both
gccgo and now go/types can compile/type-check
the entire std library (and thus all the shift
expressions occuring in it) w/o errors. For
more details see the discussion in issue 4883.

Fixes #4880.
Fixes #4881.
Fixes #4883.

R=rsc, r, iant, ken, ken, mtj, rogpeppe
CC=golang-dev
https://golang.org/cl/7707043

Generated by addca.

R=gobot
CC=golang-dev
https://golang.org/cl/7861044

Fixes #3418.

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

Also print all status changes when using hg -v.

The start_status_thread call was lost during the refactoring in
https://golang.org/cl/5395044/diff/6006/lib/codereview/codereview.py
Oops.

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

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

Results from linux/arm on a Samsung Chromebook (from dfc):
localhost(~/go/src/pkg/net) % ~/go/misc/benchcmp {old,new}.txt
benchmark                           old ns/op    new ns/op    delta
BenchmarkTCP4OneShot                   568840       350526  -38.38%
BenchmarkTCP4OneShot-2                 359054       206708  -42.43%
BenchmarkTCP4OneShotTimeout            637464       363550  -42.97%
BenchmarkTCP4OneShotTimeout-2          374255       216695  -42.10%
BenchmarkTCP4Persistent                184974        64984  -64.87%
BenchmarkTCP4Persistent-2              109902        47195  -57.06%
BenchmarkTCP4PersistentTimeout         210039        64789  -69.15%
BenchmarkTCP4PersistentTimeout-2       124284        43374  -65.10%
BenchmarkTCP6OneShot                   672278       362116  -46.14%
BenchmarkTCP6OneShot-2                 383631       216400  -43.59%
BenchmarkTCP6OneShotTimeout            680740       378306  -44.43%
BenchmarkTCP6OneShotTimeout-2          397524       230152  -42.10%
BenchmarkTCP6Persistent                172346        65292  -62.12%
BenchmarkTCP6Persistent-2              106229        42096  -60.37%
BenchmarkTCP6PersistentTimeout         161149        65138  -59.58%
BenchmarkTCP6PersistentTimeout-2       152276        44548  -70.75%

R=golang-dev, dave, bradfitz, dvyukov, rsc
CC=golang-dev
https://golang.org/cl/7820045

In addition to fixing the bug, the check is now linear instead of quadratic.

Fixes #4469.

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

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

R=golang-dev, rsc, mikioh.mikioh
CC=golang-dev
https://golang.org/cl/7857044

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

They are making the build die. I want to be able to see that everything else is okay.

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

R=golang-dev
CC=dvyukov, golang-dev, rsc
https://golang.org/cl/7845043

Thanks to jon.forums@ for the fix.

Fixes #5051.

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

Fix signal handling so that Go builds on NetBSD.

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

It used to not mark parameters as escaping if only one of the
fields it points to leaks out of the function. This causes
problems when importing from another package.

Fixes #4964.

R=rsc, lvd, dvyukov, daniel.morsing
CC=golang-dev
https://golang.org/cl/7648045

Note: BitTarget will be removed by a forthcoming changeset.

R=golang-dev, dvyukov
CC=golang-dev, rsc
https://golang.org/cl/7837044

R=golang-dev, rsc
CC=golang-dev, nigeltao
https://golang.org/cl/7812044

This provides a way to generate core dumps when people need them.
The settings are:

        GOTRACEBACK=0  no traceback on panic, just exit
        GOTRACEBACK=1  default - traceback on panic, then exit
        GOTRACEBACK=2  traceback including runtime frames on panic, then exit
        GOTRACEBACK=crash traceback including runtime frames on panic, then crash

Fixes #3257.

R=golang-dev, devon.odell, r, daniel.morsing, ality
CC=golang-dev
https://golang.org/cl/7666044

Small change to cmd/gc to catch a "fallthrough" in the final case of a switch.

R=golang-dev, rsc, mtj
CC=golang-dev
https://golang.org/cl/7841043

R=seed, rminnich, bradfitz, r
CC=golang-dev
https://golang.org/cl/7395059

Fixes #4268.
Fixes #4491.

R=golang-dev, nightlyone, fullung, r
CC=golang-dev
https://golang.org/cl/7546048

CL 7799045 relaxed the restriction in cmd/go on ~ in GOPATH
to allow paths with ~ in the middle while continuing to
protect against the common mistake of using GOPATH='~/home'
instead of GOPATH=~/home.  Unfortunately go/build still
filters these paths out:

        $ GOPATH=/tmp/test~ing go build
        test.go:22:2: cannot find package "test" in any of:
                /usr/lib/go/test (from $GOROOT)
                ($GOPATH not set)

So relax the requirement in go/build, too.

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

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

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

NEGL does a negation of the bottom 32 bits and then zero-extends to 64 bits,
resulting in a negative 32-bit number but a positive 64-bit number.

NEGQ does a full 64-bit negation, so that the result is negative both as
a 32-bit and as a 64-bit number.

This doesn't matter for the functions that are declared to return int32.
It only matters for the ones that return int64 or void* [sic].

This will fix the current incorrect error in the OpenBSD/amd64 build.
The build will still be broken, but it won't report a bogus error.

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

I picked everyone who has committed a CL on behalf of someone else in recent times.

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

The database/sql/driver docs make this promise:

   "Conn is a connection to a database. It is not used
   concurrently by multiple goroutines."

That promises exists as part of database/sql's overall
goal of making drivers relatively easy to write.

So far this promise has been kept without the use of locks by
being careful in the database/sql package, but sometimes too
careful. (cf. golang.org/issue/3857)

The CL associates a Mutex with each driver.Conn, and with the
interface value progeny thereof. (e.g. each driver.Tx,
driver.Stmt, driver.Rows, driver.Result, etc) Then whenever
those interface values are used, the Locker is locked.

This CL should be a no-op (aside from some new Lock/Unlock
pairs) and doesn't attempt to fix Issue 3857 or Issue 4459,
but should make it much easier in a subsequent CL.

Update #3857

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

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