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

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

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

Reimplement the test based on code from adg@golang.org.

The previous version has a race since the file is closed via defer
rather than in the go routine. This meant that the file could be
closed before the go routine has actually received io.EOF. It then
receives EBADF and continues to do zero-byte writes to the pipe.

This addresses an issue seen on FreeBSD and OpenBSD, where the test
passes but exits with a SIGPIPE, resulting in a failure.

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

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

Without this change it's possible to launch godoc,
immediately GET /, and see a directory listing instead of root.html

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

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

Fixes #2755

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

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

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

work in progress, and we are not ready to freeze its API for Go 1.

Package html still exists, containing just two functions: EscapeString
and UnescapeString.

Both the packages at exp/html and html are "package html". The former
is a superset of the latter.

At some point in the future, the exp/html code will move back into
html, once we have finalized the parser API.

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

Marshaler has a number of open areas that need
further thought (e.g. it doesn't handle attributes,
it's supposed to handle tag names internally but has
no information to do so, etc).

We're removing it now and will bring it back with an
interface that covers these aspects, after Go 1.

Related to issue 2771, but doesn't fix it.

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

R=golang-dev, bradfitz, rsc, r, gri, r
CC=golang-dev
https://golang.org/cl/5543047

That was supposed to be in the original CL, but missed
the files.

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

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

Fixes #2628

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

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

        In order to allow buildscript.sh to generate buildscripts for all
        $GOOS/$GOARCH combinations, we have to generate dummy files for cmd/go.
        Fixes #2586.

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

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

Fixes #2759.

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

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

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

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

Also, add an explicit error type when the right hand side is an unexported
function.

R=golang-dev, gri, rogpeppe, agl, rsc
CC=golang-dev
https://golang.org/cl/5564048

Fixes #2700.

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

Includes gofix module. The only case not covered should be
xml.Unmarshal, since it remains with a similar interface, and
would require introspecting the type of its first argument
better.

Fixes #2626.

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

CL 5572043 removed the last uses of this field.
The information is readily available from Type.Decl.

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

R=nigeltao, christoph, rsc, r, tux21b
CC=golang-dev
https://golang.org/cl/5573048

Also: remove an unused template variable declaration.

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

The bitLen function currently shifts out blocks of 8 bits at a time.
This change replaces this sorta-linear algorithm with a log(N)
one (shift out 16 bits, then 8, then 4, then 2, then 1).
I left the start of it linear at 16 bits at a time so that
the function continues to work with 32 or 64 bit values
without any funkiness.
The algorithm is similar to several of the nlz ("number of
leading zeros") algorithms from "Hacker's Delight" or the
"bit twiddling hacks" pages.

Doesn't make a big difference to the existing benchmarks, but
I'm using the code in a different context that calls bitLen
much more often, so it seemed worthwhile making the existing
codebase faster so that it's a better building block.

Microbenchmark results on a 64-bit Macbook Pro using 6g from weekly.2012-01-20:

benchmark                old ns/op    new ns/op    delta
big.BenchmarkBitLen0             4            6  +50.12%
big.BenchmarkBitLen1             4            6  +33.91%
big.BenchmarkBitLen2             6            6   +3.05%
big.BenchmarkBitLen3             7            6  -19.05%
big.BenchmarkBitLen4             9            6  -30.19%
big.BenchmarkBitLen5            11            6  -42.23%
big.BenchmarkBitLen8            16            6  -61.78%
big.BenchmarkBitLen9             5            6  +18.29%
big.BenchmarkBitLen16           18            7  -60.99%
big.BenchmarkBitLen17            7            6   -4.64%
big.BenchmarkBitLen31           19            7  -62.49%

On an ARM machine (with the previous weekly):

benchmark                old ns/op    new ns/op    delta
big.BenchmarkBitLen0            37           50  +36.56%
big.BenchmarkBitLen1            59           51  -13.69%
big.BenchmarkBitLen2            74           59  -20.40%
big.BenchmarkBitLen3            92           60  -34.89%
big.BenchmarkBitLen4           110           59  -46.09%
big.BenchmarkBitLen5           127           60  -52.68%
big.BenchmarkBitLen8           181           59  -67.24%
big.BenchmarkBitLen9            78           60  -23.05%
big.BenchmarkBitLen16          199           69  -65.13%
big.BenchmarkBitLen17           91           70  -23.17%
big.BenchmarkBitLen31          210           95  -54.43%

R=golang-dev, dave, edsrzf, gri
CC=golang-dev
https://golang.org/cl/5570044