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

It means serious user error that can lead to
hard to debug issues under load, log entry
will not harm.

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

Fixes #2781.

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

Fixes test/reorder2.go for all cases tripped up with -lll in 5555072

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

Fixes #2752.

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

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

If there's an error, sometimes you need to stop.
Part of issue 2787.

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

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

Fixes #2784

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

The idea is that we add files to the api/ directory which
are sets of promises for the future.  Each line in a file
is a stand-alone feature description.

When we do a release, we make sure we haven't broken or changed
any lines from the past (only added them).

We never change old files, only adding new ones. (go-1.1.txt,
etc)

R=dsymonds, adg, r, remyoudompheng, rsc
CC=golang-dev
https://golang.org/cl/5570051

Fixes #2699

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

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

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

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

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

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

Separating Method from Func made the code only more complicated
without adding much to the useability/readability of the API.
Reverted to where it was, but leaving the new method-specific
fields Orig and Level.

Former clients (godoc) of doc.Method only used the Func fields;
and because Func was embedded, no changes are needed with respect
to the removal of Method.

Changed type of Func.Recv from ast.Expr to string. This was a
long-standing TODO. Also implemented Func.Orig field (another TODO).

No further go/doc API changes are expected for Go 1.

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

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

This improves the handling of xml.Unmarshal in
the xmlapi fix by guessing some of the common
types used on it.

This also fixes a bug in the partial typechecker.
In an expression such as f(&a), it'd mark a as
having &T rather than *T.

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

Roughly 2x speedup for the internal bitLen function in arith.go.  Added TestWordBitLen test.

Performance differences against the new version of
bitLen generic:

x86-64 Macbook pro (current tip):

benchmark                old ns/op    new ns/op    delta
big.BenchmarkBitLen0             6            4  -37.40%
big.BenchmarkBitLen1             6            2  -51.79%
big.BenchmarkBitLen2             6            2  -65.04%
big.BenchmarkBitLen3             6            2  -66.10%
big.BenchmarkBitLen4             6            2  -60.96%
big.BenchmarkBitLen5             6            2  -55.80%
big.BenchmarkBitLen8             6            2  -56.19%
big.BenchmarkBitLen9             6            2  -64.73%
big.BenchmarkBitLen16            7            2  -68.84%
big.BenchmarkBitLen17            6            2  -67.11%
big.BenchmarkBitLen31            7            2  -61.57%

386 Intel Atom (current tip):
benchmark                old ns/op    new ns/op    delta
big.BenchmarkBitLen0            23           20  -13.04%
big.BenchmarkBitLen1            23           20  -14.77%
big.BenchmarkBitLen2            24           20  -19.28%
big.BenchmarkBitLen3            25           20  -21.57%
big.BenchmarkBitLen4            24           20  -16.94%
big.BenchmarkBitLen5            25           20  -20.78%
big.BenchmarkBitLen8            24           20  -19.28%
big.BenchmarkBitLen9            25           20  -20.47%
big.BenchmarkBitLen16           26           20  -23.37%
big.BenchmarkBitLen17           26           20  -25.09%
big.BenchmarkBitLen31           32           20  -35.51%

ARM v5 SheevaPlug, previous weekly patched with bitLen:
benchmark                old ns/op    new ns/op    delta
big.BenchmarkBitLen0            50           29  -41.73%
big.BenchmarkBitLen1            51           29  -42.75%
big.BenchmarkBitLen2            59           29  -50.08%
big.BenchmarkBitLen3            60           29  -50.75%
big.BenchmarkBitLen4            59           29  -50.08%
big.BenchmarkBitLen5            60           29  -50.75%
big.BenchmarkBitLen8            59           29  -50.08%
big.BenchmarkBitLen9            60           29  -50.75%
big.BenchmarkBitLen16           69           29  -57.35%
big.BenchmarkBitLen17           70           29  -57.89%
big.BenchmarkBitLen31           95           29  -69.07%

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

This patch intend to fix following issues.
http://code.google.com/p/go/issues/detail?id=2616

Fixes #2616.

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

Pulling function calls out to happen before the
expression being evaluated was causing illegal
reorderings even without inlining; with inlining
it got worse.  This CL adds a separate ordering pass
to move things with a fixed order out of expressions
and into the statement sequence, where they will
not be reordered by walk.

Replaces lvd's CL 5534079.

Fixes #2740.

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

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

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

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

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

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

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

I said rm, but not hg rm.
I never was good at Simon says.

TBR=bradfitz
CC=golang-dev
https://golang.org/cl/5574066

The real fix for Issue 2616 is in
https://golang.org/cl/5532057, to be submitted
following this CL, without the test there which doesn't work
reliably. This one seems to.

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

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

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

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

Python and Mercurial are a matched pair.

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

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

Added a cache to compensate for extra call overhead.
go test -bench=Print marginally faster (in the noise).

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

No changes when applying gofmt to src, misc.

Fixes #2597.

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

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

The implementation is divided into 4 phases:
1) export filtering of an incoming AST if necessary (exports.go)
2) reading of a possibly filtered AST (reader.go: type reader)
3) method set computation (reader.go)
4) sorting and creation of final documentation (reader.go)

In contrast to the old implementation, the presentation data
(Names, Docs, Decls, etc.) are created immediately upon reading
the respective AST node. Also, all types are collected (embedded
or not) in a uniform way.

Once the entire AST has been processed, all methods and types
have been collected and the method sets for each type can be
computed (phase 3).

To produce the final documentation, the method sets and value
maps are sorted.

There are no API changes. Passes the existing test suite unchanged.

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

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