CL 4313064 fixed its test case but did not address a
general enough problem:

type T1 struct { F *T2 }
type T2 T1
type T3 T2

could still end up copying the definition of T1 for T2
before T1 was done being evaluated, or T3 before T2
was done.

In order to propagate the updates correctly,
record a copy of an incomplete type for re-execution
once the type is completed. Roll back CL 4313064.

Fixes #3709.

R=ken2
CC=golang-dev, lstoakes
https://golang.org/cl/6301059

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

Fixes #3607.

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

Fixes #3593.

R=ken2
CC=golang-dev, lvd
https://golang.org/cl/6305061

Fixes #3614.

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

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

This is the mechanical part of the 2-part change that started with
https://golang.org/cl/6305053/

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

This is part 1 of a 2 part changelist. Part 2 contains the mechanical
change to parse.go to compare atoms (ints) instead of strings.

The overall effect of the two changes are:
benchmark                      old ns/op    new ns/op    delta
BenchmarkParser                  4462274      4058254   -9.05%
BenchmarkRawLevelTokenizer        913202       912917   -0.03%
BenchmarkLowLevelTokenizer       1268626      1267836   -0.06%
BenchmarkHighLevelTokenizer      1947305      1968944   +1.11%

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

As discussed in

https://groups.google.com/d/msg/golang-dev/Na9XE6mcQyY/zbeBI7R-vnoJ

Here is a static copy of the go/parser benchmark. I ended up using
fancy encodings because the original parser.go had a number of `s
scattered throughout which made it hard to embed the source directly.

Curiously on my laptop this benchmark always scores roughly 10% higher
than the standalone benchmark. This may be down to the generation of
the fasta data set triggering the cpu governor to raise the cpu speed.
However the benchmark is consistent with itself across multiple runs.

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

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

This completely covers the tags used by exp/html's parser.

Before:
295 atoms; 1406 string bytes + 2048 tables = 3454 total data
BenchmarkLookup    50000         59841 ns/op

After:
322 atoms; 1508 string bytes + 2048 tables = 3556 total data
BenchmarkLookup    50000         60159 ns/op

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

The datastore.Query methods once mutated the Query value, but now they return
a derivative query, so the Hash= and ParentHash= filters were not being
applied.

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

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

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

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

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

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

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

The reordering speedup in CL 6245068 changed the semantics
of %#v by delaying the clearing of some flags.  Restore the old
semantics and add a test.

Fixes #3706.

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

        CL 6250075 removed AI_MASK mask on all BSD variants,
        however FreeBSD's AI_MASK does not include AI_V4MAPPED
        and AI_ALL, and its libc is strict about the ai_flags.

        This will fix the FreeBSD builder.

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

        Fixes #3699.

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

On netbsd/386, tv_sec is a 64-bit integer for both timeval and timespec.
Fix the time handling code so that it works correctly.

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

This should be the last of them.

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

As discussed on golang-dev, reduce the size of the fasta
dataset to make it possible to run the go1 benchmarks on
small ARM systems.

Also, remove the 25m suffix from fasta data and Revcomp.

linux/arm: pandaboard OMAP4

BenchmarkBinaryTree17          1        70892426000 ns/op
BenchmarkFannkuch11            1        35712066000 ns/op
BenchmarkGobDecode            10         137146000 ns/op           5.60 MB/s
BenchmarkGobEncode            50          64953000 ns/op          11.82 MB/s
BenchmarkGzip          1        5675690000 ns/op           3.42 MB/s
BenchmarkGunzip        1        1207001000 ns/op          16.08 MB/s
BenchmarkJSONEncode            5         860424800 ns/op           2.26 MB/s
BenchmarkJSONDecode            1        3321839000 ns/op           0.58 MB/s
BenchmarkMandelbrot200        50          45893560 ns/op
BenchmarkRevcomp              10         135220300 ns/op          18.80 MB/s
BenchmarkTemplate              1        6385681000 ns/op           0.30 MB/s

R=rsc, minux.ma, dsymonds
CC=golang-dev
https://golang.org/cl/6278048

Thanks to Dave Cheney for the magic words "comm page".

benchmark       old ns/op    new ns/op    delta
BenchmarkNow          197           33  -83.05%

This should make profiling a little better on OS X.
The raw time saved is unlikely to matter: what likely matters
more is that it seems like OS X sends profiling signals on the
way out of system calls more often than it should; avoiding
the system call should increase the accuracy of cpu profiles.

The 386 version would be similar but needs to do different
math for CPU speeds less than 1 GHz. (Apparently Apple has
never shipped a 64-bit CPU with such a slow clock.)

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

amd64 was done in CL 6275056.

We don't attempt to handle machines with clock speeds
less than 1 GHz. Those will fall back to the system call.

benchmark       old ns/op    new ns/op    delta
BenchmarkNow          364           38  -89.53%

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

Using an int64 for a block size doesn't make
sense on 32bit platforms but extracts a performance
penalty dealing with double word quantities on Arm.

linux/arm

benchmark                 old ns/op    new ns/op    delta
BenchmarkGobDecode        155401600    144589300   -6.96%
BenchmarkGobEncode         72772220     62460940  -14.17%
BenchmarkGzip               5822632      2604797  -55.26%
BenchmarkGunzip              326321       151721  -53.51%

benchmark                  old MB/s     new MB/s  speedup
BenchmarkGobDecode             4.94         5.31    1.07x
BenchmarkGobEncode            10.55        12.29    1.16x

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

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

There already is a "Phase 6" a few lines above.

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

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

It is not necessary for the test to be effective and uses a
lot of resources in the compiler. Memory usage is halved and
compilation around 8x faster.

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

Fixes #3635.

R=rsc, r, iant, kevlar, iant
CC=golang-dev
https://golang.org/cl/6217045

The original implementation of closures created the
underlying top-level function during walk, which is fairly
late in the compilation process and caused ordering-based
complications due to earlier stages that had to be repeated
any number of times.

Create the underlying function during typecheck, much
earlier, so that later stages can be run just once.

The result is a simpler compilation sequence.

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

        although the comment says it uses libc's getenv, without NOPLAN9DEFINES
        it actually uses p9getenv which strdups.

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

The recent shuffle in parsing formats exposed probably unintentional
behavior in time.Parse, namely that it was mostly ignoring ".99999"
in the format, producing the following behavior:

fmt.Println(time.Parse("03:04:05.999 MST", "12:00:00.888 PDT")) // error (.888 unexpected)
fmt.Println(time.Parse("03:04:05.999", "12:00:00")) // error (input too short)
fmt.Println(time.Parse("03:04:05.999 MST", "12:00:00 PDT"))  // ok (extra bytes on input make it ok)

http://play.golang.org/p/ESJ1UYXzq2

API CHANGE:

This CL makes all three examples valid: ".999" can match an
empty string or else a fractional second with at most nine digits.

Fixes #3701.

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

An attempt to profit from CL 6176043 (fix to superpolinomial
runtime of karatsuba multiplication) and determine a better
karatsuba threshold. The result indicates that 32 is still
a reasonable value. Left the threshold as is (== 32), but
made some minor changes to the calibrate code which are
worthwhile saving (use of existing benchmarking code for
better results, better use of package time).

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

Regenerated tables using maketables.

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

      We can't depend on init() order, and certainly we don't want to
register all future benchmarks that use jsonbytes or jsondata to init()
in json_test.go, so we use a more general solution: make generation of
jsonbytes and jsondata their own function so that the compiler will take
care of the order.

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

Fix botched cgo_netbsd.go merge and remove redundant +build directive.

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

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