Fixes #4596.

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

Also:
- put GORACE into the go env command
- do minor housekeeping on the race detector article

Fixes #4995.

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

Fixes #5053.

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

- comment fixes
- s/z/x/ in (*rat).Float64 to match convention for functions
  returning a non-*Rat
- minor test output tweaking

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

See https://github.com/raggi/go-and-java for runtime benchmark.

The patch reduces the amount of map key search, moving connection oriented
variables onto the connection structs.

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

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

Also fix the sort order of the laundry list.

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

The smtp package originally allowed PLAIN whenever, but then
the TLS check was added for paranoia, but it's too paranoid:
it prevents using PLAIN auth even from localhost to localhost
when the server advertises PLAIN support.

This CL also permits the client to send PLAIN if the server
advertises it.

Fixes #5184

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

Update #4871

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

Be deliberately vague, since the precise details should not be depended upon.
Fixes #5155.

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

Just commentary, no semantic change.

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

Save an allocation per GET request and don't call io.LimitedReader(r, 0)
just to read 0 bytes.  There's already an eofReader global variable
for when we just want a non-nil io.Reader to immediately EOF.

(Sorry, I know Rob told me to stop, but I was bored on the plane and
wrote this before I received the recent "please, really stop" email.)

benchmark                         old ns/op    new ns/op    delta
BenchmarkServerHandlerTypeLen         13888        13279   -4.39%
BenchmarkServerHandlerNoLen           12912        12229   -5.29%
BenchmarkServerHandlerNoType          13348        12632   -5.36%
BenchmarkServerHandlerNoHeader        10911        10261   -5.96%

benchmark                        old allocs   new allocs    delta
BenchmarkServerHandlerTypeLen            20           19   -5.00%
BenchmarkServerHandlerNoLen              18           17   -5.56%
BenchmarkServerHandlerNoType             18           17   -5.56%
BenchmarkServerHandlerNoHeader           13           12   -7.69%

benchmark                         old bytes    new bytes    delta
BenchmarkServerHandlerTypeLen          1913         1878   -1.83%
BenchmarkServerHandlerNoLen            1878         1843   -1.86%
BenchmarkServerHandlerNoType           1878         1844   -1.81%
BenchmarkServerHandlerNoHeader         1085         1051   -3.13%

Fixes #5188

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

Fixes inscrutable GC faults during testing.

R=golang-dev, bradfitz, dave, fullung
CC=golang-dev
https://golang.org/cl/8300044

My old code was trying to be too smart.
Also: Slightly better error message format
for gofmt -r pattern errors.

Fixes #4406.

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

Generated by addca.

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

Fixes #5141.

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

A nested TFORW type would push algtype1 into an impossible case.

Fixes #5125.

R=golang-dev, daniel.morsing
CC=golang-dev
https://golang.org/cl/8213043

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

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

Also remove the introduction, which says what the rest of the
page says anyway.

Fixes #5182.

R=golang-dev, kamil.kisiel, r
CC=golang-dev
https://golang.org/cl/8281044

This changes the map lookup behavior for string maps with 2-8 keys.

There was already previously a fastpath for 0 items and 1 item.

Now, if a string-keyed map has <= 8 items, first check all the
keys for length first. If only one has the right length, then
just check it for equality and avoid hashing altogether. Once
the map has more than 8 items, always hash like normal.

I don't know why some of the other non-string map benchmarks
got faster. This was with benchtime=2s, multiple times. I haven't
anything else getting slower, though.

benchmark                             old ns/op    new ns/op    delta
BenchmarkHashStringSpeed                     37           34   -8.20%
BenchmarkHashInt32Speed                      32           29  -10.67%
BenchmarkHashInt64Speed                      31           27  -12.82%
BenchmarkHashStringArraySpeed               105           99   -5.43%
BenchmarkMegMap                          274206       255153   -6.95%
BenchmarkMegOneMap                           27           23  -14.80%
BenchmarkMegEqMap                        148332       116089  -21.74%
BenchmarkMegEmptyMap                          4            3  -12.72%
BenchmarkSmallStrMap                         22           22   -0.89%
BenchmarkMapStringKeysEight_32               42           23  -43.71%
BenchmarkMapStringKeysEight_64               55           23  -56.96%
BenchmarkMapStringKeysEight_1M           279688           24  -99.99%
BenchmarkIntMap                              16           15  -10.18%
BenchmarkRepeatedLookupStrMapKey32           40           37   -8.15%
BenchmarkRepeatedLookupStrMapKey1M       287918       272980   -5.19%
BenchmarkNewEmptyMap                        156          130  -16.67%

R=golang-dev, khr
CC=golang-dev
https://golang.org/cl/7641057

Also, move an existing benchmark from map_test.go to
mapspeed_test.go.

R=golang-dev, khr
CC=golang-dev
https://golang.org/cl/8294043

Update #4553.

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

It was unnecessarily cloning and then mutating a map that had
a very short lifetime (just that function).

No new tests, because they were added in revision 833bf2ef1527
(TestHeaderToWire). The benchmarks below are from the earlier
commit, revision 52e3407d.

I noticed this inefficiency when reviewing a change Peter Buhr
is looking into, which will also use these benchmarks.

benchmark                         old ns/op    new ns/op    delta
BenchmarkServerHandlerTypeLen         12547        12325   -1.77%
BenchmarkServerHandlerNoLen           12466        11167  -10.42%
BenchmarkServerHandlerNoType          12699        11800   -7.08%
BenchmarkServerHandlerNoHeader        11901         9210  -22.61%

benchmark                        old allocs   new allocs    delta
BenchmarkServerHandlerTypeLen            21           20   -4.76%
BenchmarkServerHandlerNoLen              20           18  -10.00%
BenchmarkServerHandlerNoType             20           18  -10.00%
BenchmarkServerHandlerNoHeader           17           13  -23.53%

benchmark                         old bytes    new bytes    delta
BenchmarkServerHandlerTypeLen          1930         1913   -0.88%
BenchmarkServerHandlerNoLen            1912         1879   -1.73%
BenchmarkServerHandlerNoType           1912         1878   -1.78%
BenchmarkServerHandlerNoHeader         1491         1086  -27.16%

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

(amd64)
benchmark           old ns/op    new ns/op    delta
BenchmarkEqual0            16            6  -63.15%
BenchmarkEqual9            22            7  -65.37%
BenchmarkEqual32           36            9  -74.91%
BenchmarkEqual4K         2187          120  -94.51%

benchmark            old MB/s     new MB/s  speedup
BenchmarkEqual9        392.22      1134.38    2.89x
BenchmarkEqual32       866.72      3457.39    3.99x
BenchmarkEqual4K      1872.73     33998.87   18.15x

(386)
benchmark           old ns/op    new ns/op    delta
BenchmarkEqual0            16            5  -63.85%
BenchmarkEqual9            22            7  -67.84%
BenchmarkEqual32           34           12  -64.94%
BenchmarkEqual4K         2196          113  -94.85%

benchmark            old MB/s     new MB/s  speedup
BenchmarkEqual9        405.81      1260.18    3.11x
BenchmarkEqual32       919.55      2631.21    2.86x
BenchmarkEqual4K      1864.85     36072.54   19.34x

Update #3751

R=bradfitz, r, khr, dave, remyoudompheng, fullung, minux.ma, ality
CC=golang-dev
https://golang.org/cl/8056043

For all the Content-Type & Content-Length cases.

R=golang-dev, pabuhr
CC=golang-dev
https://golang.org/cl/8280046

A package file may begin as either "package foo" or
"package foo safe". The latter is relevant when using -u.
https://golang.org/cl/6903059 resulted in the distinction
being dropped when a package was read for the second or later time.
This CL records whether that "safe" tag was present,
and includes it in the dummy statement generated for the lexer.

R=golang-dev, r, minux.ma, daniel.morsing, iant
CC=golang-dev
https://golang.org/cl/8255044

The expected precision setting for the x87 on Win32 is 53-bit
but MinGW resets the floating point unit to 64-bit.  Win32
object code generally expects values to be rounded to double,
not double extended, precision.

R=golang-dev, khr
CC=golang-dev
https://golang.org/cl/8175044

Per discussions on golang-nuts and golang-dev:
"Some concerns with DialOpt"
https://groups.google.com/d/msg/golang-nuts/Hfh9aqhXyUw/W3uYi8lOdKcJ
https://groups.google.com/d/msg/golang-dev/37omSQeWv4Y/KASGIfPpXh0J

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

Fixes #5059.

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

Fixes #5181.

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

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

Fixes #5186.

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

s/ordering/less/g

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

Demonstrates one way to sort a slice of structs according
to different sort criteria, done in sequence.

One possible answer to a question that comes up often.

R=golang-dev, gri, bradfitz, adg, adg, rogpeppe
CC=golang-dev
https://golang.org/cl/8182044

From a discussion on golang-nuts.

R=golang-dev, dsymonds, nigeltao, coocood, adg
CC=golang-dev
https://golang.org/cl/8251043

(x<<1 | x>>31).

Fixes #5084.

On the SHA3 benchmark proposals at
https://golang.org/cl/7760044/

benchmark                       old ns/op    new ns/op    delta
BenchmarkPermutationFunction         1288         1191   -7.53%
BenchmarkSingleByteWrite             5795         5811   +0.28%
BenchmarkBlockWrite512                178          179   +0.56%
BenchmarkBlockWrite384                230          233   +1.30%
BenchmarkBlockWrite256                282          286   +1.42%
BenchmarkBlockWrite224                301          306   +1.66%
BenchmarkBulkHashSHA3_512          326885       304548   -6.83%
BenchmarkBulkHashSHA3_384          234839       220074   -6.29%
BenchmarkBulkHashSHA3_256          186969       175790   -5.98%
BenchmarkBulkHashSHA3_224          178133       167489   -5.98%

For a function like

func g() {
        x = a[3]<<20 | a[3]>>12
}

the asm goes from

0006 (main.go:10) TEXT    g+0(SB),$0-0
0007 (main.go:10) MOVL    a+12(SB),BP
0008 (main.go:10) LOCALS  ,$0
0009 (main.go:11) MOVL    BP,BX
0010 (main.go:11) SHLL    $20,BX
0011 (main.go:11) SHRL    $12,BP
0012 (main.go:11) ORL     BP,BX
0013 (main.go:11) MOVL    BX,x+0(SB)
0014 (main.go:12) RET     ,

to

0006 (main.go:10) TEXT    g+0(SB),$0-0
0007 (main.go:10) LOCALS  ,$0
0008 (main.go:11) MOVL    a+12(SB),BX
0009 (main.go:11) ROLL    $20,BX
0010 (main.go:11) MOVL    BX,x+0(SB)
0011 (main.go:12) RET     ,

R=rsc, iant, remyoudompheng
CC=golang-dev, jcb
https://golang.org/cl/7944043

Mention support for NetBSD, OpenBSD, and cgo for linux/arm.

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

Doing grow work on reads is not multithreaded safe.
Changed code to do grow work only on inserts & deletes.

This is a short-term fix, eventually we'll want to do
grow work in parallel to recover the space of the old
table.

Fixes #5120.

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

Fixes #5176.

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