[]byte("string") was simplifying to
[]byte{0: 0x73, 1: 0x74, 2: 0x72, 3: 0x69, 4: 0x6e, 5: 0x67},
but that latter form takes up much more memory in the compiler.
Preserve the string form and recognize it to turn global variables
initialized this way into linker-initialized data.

Reduces the compiler memory footprint for a large []byte initialized
this way from approximately 10 kB/B to under 100 B/B.

See also issue 6643.

R=golang-codereviews, r, iant, oleku.konko, dave, gobot, bradfitz
CC=golang-codereviews
https://golang.org/cl/15930045

Usually when a message is signed it's first hashed because RSA has low
limits on the size of messages that it can sign. However, some
protocols sign short messages directly. This isn't a great idea because
the messages that can be signed suddenly depend on the size of the RSA
key, but several people on golang-nuts have requested support for
this and it's very easy to do.

R=golang-codereviews, rsc
CC=golang-codereviews
https://golang.org/cl/44400043

See https://golang.org/cl/44150043/

««« original CL description
regexp: use sync.Pool

For machines, not threads.

Update #4720

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

TBR=golang-dev
CC=golang-codereviews
https://golang.org/cl/48190043

ZIP64 Extra records are variably sized, but we weren't capping
our reading of the extra fields at its previously-declared
size.

No test because I don't know how to easily create such files
and don't feel like manually construction one.  But all
existing tests pass, and this is "obviously correct" (queue
laughter).

Fixes #7069

R=golang-codereviews, iant
CC=golang-codereviews
https://golang.org/cl/48150043

Adds tests for branches handling call ordering which
were shown to be untested by the cover tool.

This is part of the refactoring of form parsing discussed
in CL 44040043. These tests may need to be changed later but
should help lock in the current behaviour.

R=golang-codereviews, dave, bradfitz
CC=golang-codereviews
https://golang.org/cl/46750043

R=golang-codereviews, bradfitz
CC=golang-codereviews
https://golang.org/cl/47570043

R=golang-codereviews, gobot, r, bradfitz
CC=golang-codereviews
https://golang.org/cl/37660044

Benchmark on Intel(R) Core(TM) i5-2500S CPU @ 2.70GHz (albeit in a VM)

benchmark              old ns/op    new ns/op    delta
BenchmarkHash8Bytes         1606          699  -56.48%
BenchmarkHash1K            21920         7268  -66.84%
BenchmarkHash8K           165696        53756  -67.56%

benchmark               old MB/s     new MB/s  speedup
BenchmarkHash8Bytes         4.98        11.44    2.30x
BenchmarkHash1K            46.72       140.88    3.02x
BenchmarkHash8K            49.44       152.39    3.08x

R=agl, cldorian
CC=golang-codereviews
https://golang.org/cl/44800044

The Domain and Path field of a parsed cookie have been
the unprocessed wire data since Go 1.0; this seems to
be okay for most applications so let's keep it.

Returning the unprocessed wire data makes it easy to
handle nonstandard or even broken clients without
consulting Raw or Unparsed of a cookie.

The RFC 6265 parsing rules for domain and path are
currently buried in net/http/cookiejar but could be
exposed in net/http if necessary.

R=bradfitz, nigeltao
CC=golang-codereviews
https://golang.org/cl/48060043

Document what values a PublicSuffixList must accept as
a domain in a call to PublicSuffix.

R=bradfitz, nigeltao
CC=golang-codereviews
https://golang.org/cl/47560044

Fixes #7063.

R=golang-codereviews, iant
CC=golang-codereviews
https://golang.org/cl/47950043

Require at least one space after "type" and do not fontify closing
parenthesis of type switch as a type.

R=adonovan
CC=golang-codereviews
https://golang.org/cl/37720050

R=adonovan
CC=golang-codereviews
https://golang.org/cl/23290044

Use copy rather than a hand rolled loop when moving a partial input
block to the scratch area. This results in a reasonable performance
gain when partial blocks are written.

Benchmarks on Intel(R) Xeon(R) CPU X5650  @ 2.67GHz with Go amd64:

       benchmark               old MB/s     new MB/s  speedup
SHA1   BenchmarkHash8Bytes        18.37        22.80    1.24x
SHA256 BenchmarkHash8Bytes        11.86        13.78    1.16x
SHA512 BenchmarkHash8Bytes         4.51         5.24    1.16x

       benchmark              old ns/op    new ns/op    delta
SHA1   BenchmarkHash8Bytes          435          350  -19.54%
SHA256 BenchmarkHash8Bytes          674          580  -13.95%
SHA512 BenchmarkHash8Bytes         1772         1526  -13.88%

R=agl, dave, bradfitz
CC=golang-codereviews
https://golang.org/cl/35840044

R=golang-codereviews, dave, gobot, bradfitz, gri
CC=golang-codereviews
https://golang.org/cl/46640043

R=golang-codereviews, r, aram
CC=0intro, golang-codereviews, rsc
https://golang.org/cl/43420045

No change to the meaning, just bad writing found by
Doug McIlroy.
Let's start the new year off with a bang.

R=golang-codereviews, bradfitz, dave
CC=golang-codereviews
https://golang.org/cl/47110044

when comparing kinds.

R=dvyukov, dave, khr
CC=golang-codereviews
https://golang.org/cl/41660045

Fixes #7003.

R=golang-codereviews, bradfitz
CC=golang-codereviews
https://golang.org/cl/47780043

R=shawn.p.smith, gobot, r
CC=golang-codereviews
https://golang.org/cl/46820043

Fixes #7043.

Test coming in https://golang.org/cl/46820043

R=r, bradfitz
CC=golang-codereviews
https://golang.org/cl/38330045

Fixes #6406.

R=golang-codereviews, bradfitz
CC=golang-codereviews
https://golang.org/cl/46900043

encoding/json: Fix missing error when trying to unmarshal null string into int, for successive ,string option

Fixes #7046.

R=golang-codereviews, bradfitz
CC=golang-codereviews
https://golang.org/cl/47260043

Most BSDs include the trailing NUL character of the socket path in the
length, however some do not (such as NetBSD 6.99). Handle this by only
subtracting the family and length bytes from the returned length, then
scanning the path and removing any terminating NUL bytes.

Fixes #6627.

R=golang-codereviews, mikioh.mikioh
CC=golang-codereviews
https://golang.org/cl/46420044

Some builders broke on this test; I'm guessing that was because
this test didn't try hard enough to find a different iteration order.

Update #6719

R=dave
CC=golang-codereviews
https://golang.org/cl/47300043

Technically the spec does not guarantee that the iteration order is random,
but it is a property that we have consciously pursued, and so it seems
right to verify that our implementation does indeed randomise.

Update #6719.

R=khr, bradfitz
CC=golang-codereviews
https://golang.org/cl/47010043

Generated by addca.

R=gobot
CC=golang-codereviews
https://golang.org/cl/39780047

R=golang-codereviews, bradfitz
CC=golang-codereviews
https://golang.org/cl/46880043

R=golang-codereviews, rsc, dave
CC=golang-codereviews
https://golang.org/cl/42440043

R=golang-codereviews, shawn.p.smith
CC=golang-codereviews
https://golang.org/cl/41960047

R=golang-codereviews, dave
CC=golang-codereviews
https://golang.org/cl/42990045

R=golang-codereviews, dave, bradfitz
CC=golang-codereviews
https://golang.org/cl/46250043

R=golang-codereviews, dave
CC=golang-codereviews
https://golang.org/cl/46450043

R=golang-codereviews, dave
CC=golang-codereviews
https://golang.org/cl/46270043

This source file, when compiled with gcc 4.4.3 on Ubuntu lucid,
corresponds instruction for instruction to the binaries in the same
directory.

Shipping this source code file resolves http://bugs.debian.org/716853

R=golang-codereviews, iant
CC=golang-codereviews
https://golang.org/cl/46780043

R=golang-codereviews, dave
CC=golang-codereviews
https://golang.org/cl/46470043

R=adg, djd, mpvl, nigeltao
CC=golang-codereviews
https://golang.org/cl/46660043

R=golang-codereviews, dave
CC=golang-codereviews
https://golang.org/cl/46400044

R=golang-codereviews, dave
CC=golang-codereviews
https://golang.org/cl/46630044

R=golang-codereviews, bradfitz, dave
CC=golang-codereviews
https://golang.org/cl/46600043