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

Also, don't build the tour when making the source distribution.

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

R=golang-dev, dave
CC=golang-dev
https://golang.org/cl/8342046

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

The compilers used to generate only one 'm' symbol
to record the stack frame size for each function.

In cmd/nm, the 'm' and 'f' symbols are handled in
the same switch case with a special exception for
the symbol described above called ".frame".

Now that the compilers emit additional 'm' symbols
for precise garbage collection of the stack, the
current logic is incorrect. cmd/nm will attempt to
interpret these new 'm' symbols as 'f' symbols and
add them to the file name index table.

This fails with an out-of-memory condition when
zenter encounters an 'm' symbol with a very large
value (usually the .args symbol indicating a
variadic NOSPLIT function).

R=iant
CC=dave, gobot, golang-dev, rsc
https://golang.org/cl/7962045

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

Fixes 5164.

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

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

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

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

Fixes #5175.
Race detector runtime expects values passed to MapShadow() to be page-aligned,
because they are used in mmap() call. If they are not aligned mmap() trims
either beginning or end of the mapping.

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

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

This version just tells you what to do, rather
than trying to teach you how it all works.
Should be much better for newcomers.

R=dave, gary.burd, alcosholik, r
CC=golang-dev
https://golang.org/cl/8247044

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