I will use different approach to solve this problem.
See CL 143160046 for details.

««« original CL description
syscall: keep Windows syscall pointers live too

Like https://golang.org/cl/139360044

LGTM=rsc, alex.brainman
R=alex.brainman, rsc
CC=golang-codereviews
https://golang.org/cl/138250043
»»»

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

The %#v verb is special: it says all values below need to print as %#v.
However, for some situations the # flag has other meanings and this
causes some issues, particularly in how Formatters work. Since %#v
dominates all formatting, translate it into actual state of the formatter
and decouple it from the # flag itself within the calculations (although
it must be restored when methods are doing the work.)
The result is cleaner code and correct handling of # for Formatters.
TODO: Apply the same thinking to the + flag in a followup CL.

Also, the wasString return value in handleMethods is always false,
so eliminate it.

Update #8835

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

The documentation states that Exp(x, y, m)
computes x**y mod |m| for m != nil && m > 0.
In math.big, Mod is the Euclidean modulus,
which is always >= 0.

Fixes #8822.

LGTM=agl, r, rsc
R=agl, r, rsc
CC=golang-codereviews
https://golang.org/cl/145650043

In the process, simplified internal sizeOf and
dataSize functions. Minor positive impact on
performance. Added test case.

benchmark                         old ns/op     new ns/op     delta
BenchmarkReadSlice1000Int32s      14006         14122         +0.83%
BenchmarkReadStruct               2508          2447          -2.43%
BenchmarkReadInts                 921           928           +0.76%
BenchmarkWriteInts                2086          2081          -0.24%
BenchmarkWriteSlice1000Int32s     13440         13497         +0.42%
BenchmarkPutUvarint32             28.5          26.3          -7.72%
BenchmarkPutUvarint64             81.3          76.7          -5.66%

benchmark                         old MB/s     new MB/s     speedup
BenchmarkReadSlice1000Int32s      285.58       283.24       0.99x
BenchmarkReadStruct               27.90        28.60        1.03x
BenchmarkReadInts                 32.57        32.31        0.99x
BenchmarkWriteInts                14.38        14.41        1.00x
BenchmarkWriteSlice1000Int32s     297.60       296.36       1.00x
BenchmarkPutUvarint32             140.55       151.92       1.08x
BenchmarkPutUvarint64             98.36        104.33       1.06x

Fixes #6818.

LGTM=r
R=r
CC=golang-codereviews
https://golang.org/cl/149290045

Fixes #8447.

LGTM=iant
R=golang-codereviews, bradfitz, iant
CC=golang-codereviews
https://golang.org/cl/126190043

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

envi needs to be updated during Setenv so the key can be correctly deleted later with Unsetenv.

Update #8849.

LGTM=0intro
R=bradfitz, 0intro
CC=golang-codereviews
https://golang.org/cl/149300046

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

Fixes #8776.

LGTM=bradfitz
R=rsc, bradfitz
CC=golang-codereviews
https://golang.org/cl/145710043

Fixes #8305.

LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/145680044

Fixes #7306.

LGTM=r
R=r
CC=golang-codereviews
https://golang.org/cl/153820044

This new text won't stop the whining but it might focus the whining a little more.

LGTM=adg
R=golang-codereviews, adg
CC=golang-codereviews
https://golang.org/cl/146680044

This thing should never be called, but before
151960044 it was being called, incorrectly.
This is now just a precaution but let's pretend it
Fixes #8843
even though that was fixed by 151960044.
The test case was already there and ran, another mystery.

LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/151970043

LGTM=r
R=r
CC=golang-codereviews
https://golang.org/cl/151960044

Fixes #8797.

LGTM=r
R=r
CC=golang-codereviews
https://golang.org/cl/146680043

The nicest solution would be to buffer the message and only write
it if it encodes correctly, but that adds considerable memory and
CPU overhead for a very rare condition. Instead, we just shut
down the connection if this happens.
Fixes #7689.

LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/146670043

Also address a TODO, making Clearenv pass through to cgo.

Based largely on Minux's earlier https://golang.org/cl/82040044

Fixes #6423

LGTM=iant, alex.brainman, r, rsc
R=rsc, iant, r, alex.brainman
CC=golang-codereviews
https://golang.org/cl/148370043

LGTM=crawshaw
R=golang-codereviews, crawshaw
CC=golang-codereviews
https://golang.org/cl/146610043

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

LGTM=r
R=r
CC=golang-codereviews
https://golang.org/cl/149280044

The ASN.1 encoding of the CRL Distribution Points extension showed an invalid false 'IsCompound' which caused a display problem in the Windows certificate viewer.

LGTM=agl
R=agl
CC=golang-codereviews
https://golang.org/cl/143320043

+ static test

NB: there's a preexisting (dynamic) failure of test issue7978.go.

LGTM=iant
R=rsc, iant
CC=golang-codereviews
https://golang.org/cl/144650045

This is a minor cleanup following CL 142360043:

The internal parse and format functions in both packages
were almost identical - made them identical by adding an
extra parameter, and documented them as identical.

Eventually we should find a nice way to factor these functions
out, but we cannot do this now while in prep for 1.4.

No functionality change.

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

Bodies larger than 8KB (the default bufio reader size) weren't
being dumped.  Force a read of the body so they're teed into
the response buffer.

Thanks to Steven Hartland for identifying the problem.

Fixes #8089

LGTM=r
R=golang-codereviews, r
CC=adg, golang-codereviews
https://golang.org/cl/144650044

Fixes #8541.

LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/153770043

Not a language change.

Several inaccuracies were fixed:

1) A variable declaration may declare more than just one
variable.

2) Variable initialization follows the rules of assignments,
including n:1 assignments. The existing wording implied a 1:1
or n:n rule and generally was somewhat unspecific.

3) The rules for variable declarations with no types and
untyped initialization expressions had minor holes (issue 8088).

4) Clarified the special cases of assignments of untyped values
(we don't just have untyped constants, but also untyped bools,
e.g. from comparisons). The new wording is more direct.

To that end, introduced the notion of an untyped constant's
"default type" so that the same concept doesn't have to be
repeatedly introduced.

Fixes #8088.

LGTM=iant, r, rsc
R=r, rsc, iant, ken
CC=golang-codereviews
https://golang.org/cl/142320043

Right now it is always pkgname.test.exe, but if pkgname is
patch or install or setup or update, Windows thinks that
running it will install new software, so it pops up a dialog
box asking for more permission.
Renaming the binary avoids the Windows security check.

This only applies to the binary that the Go command writes
to its temporary work directory. If the user runs 'go test -c'
or any of the other ways to generate a test binary, it will
continue to use pkgname.test.exe.

Fixes #8711.

LGTM=bradfitz
R=golang-codereviews, r
CC=alex.brainman, bradfitz, golang-codereviews, iant
https://golang.org/cl/146580043

Update #8798

This is a new implementation of pprof,
written in Go instead of in Perl.
It was written primarily by Raul Silvera and
is in use for profiling programs of all languages
inside Google.

The internal structure is a bit package-heavy,
but it matches the copy used inside Google, and
since it is in an internal directory, we can make
changes to it later if we need to.

The only "new" file here is src/cmd/pprof/pprof.go,
which stitches together the Google pprof and the
Go command libraries for object file access.

I am explicitly NOT interested in style or review
comments on the rest of the files
(that is, src/cmd/pprof/internal/...).
Those are intended to stay as close to the Google
copies as possible, like we did with the pprof Perl script.

Still to do:

- Basic tests.
- Real command documentation.
- Hook up disassemblers.

LGTM=r
R=r, bradfitz, alex.brainman, dave
CC=golang-codereviews
https://golang.org/cl/153750043

Fixes #8761.

LGTM=iant
R=golang-codereviews, iant
CC=golang-codereviews, r
https://golang.org/cl/144530045

Fixes #8309.

LGTM=r
R=golang-codereviews, r
CC=golang-codereviews, iant
https://golang.org/cl/147380043

Fixes #7935.

LGTM=iant
R=golang-codereviews, iant
CC=golang-codereviews, ruiu
https://golang.org/cl/147390043

Fixes #8449.

LGTM=iant
R=golang-codereviews, iant
CC=bradfitz, golang-codereviews
https://golang.org/cl/145600044

For Go 1.3 these external packages were collapsed into
large single-file implementations stored in the cmd/objdump
directory.

For Go 1.4 we want pprof to be able to link against them too,
so move them into cmd/internal, where they can be shared.

The new files are copied from the repo in the file path (rsc.io/...).
Those repos were code reviewed during development
(mainly by crawshaw and minux), because we knew the
main repo would use them.

Update #8798

LGTM=bradfitz
R=crawshaw, bradfitz
CC=golang-codereviews
https://golang.org/cl/153750044

Raul wrote the pprof code in CL 153750043.

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

Fixes #7609.

LGTM=r
R=r
CC=golang-codereviews
https://golang.org/cl/150270043

GC types were not being generated for the garbage collector
work buffer.  The markfor object was being collected as a result.
This broke amd64p32 and maybe plan9 builds.  Why it didn't break
every build I'm not sure...

Fixes #8812

LGTM=0intro, rsc
R=golang-codereviews, dave, khr, 0intro, rsc
CC=golang-codereviews
https://golang.org/cl/149260043

Newstack runs on g0, g0->throwsplit is never set.

LGTM=rsc
R=rsc
CC=golang-codereviews, khr
https://golang.org/cl/147370043

Our traceback code needs to know the PC of several special
functions, including goexit, mcall, etc.  Make sure that
these PCs are initialized before any traceback occurs.

Fixes #8766

LGTM=rsc
R=golang-codereviews, rsc, khr, bradfitz
CC=golang-codereviews
https://golang.org/cl/145570043

See comment 4 of https://code.google.com/p/go/issues/detail?id=8483#c4:

"So if a user creates a http.Client, issues a bunch of
requests and then wants to shutdown it and all opened connections;
what is she intended to do? The report suggests that just waiting for
all pending requests and calling CloseIdleConnections won't do, as
there can be new racing connections. Obviously she can't do what
you've done in the test, as it uses the unexported function.  If this
happens periodically, it can lead to serious resource leaks (the
transport is also preserved alive).  Am I missing something?"

This CL tracks the user's intention to close all idle
connections (CloseIdleConnections sets it true; and making a
new request sets it false). If a pending dial finishes and
nobody wants it, before it's retained for a future caller, the
"wantIdle" bool is checked and it's closed if the user has
called CloseIdleConnections without a later call to make a new
request.

Fixes #8483

LGTM=adg
R=golang-codereviews, dvyukov, adg
CC=golang-codereviews, rsc
https://golang.org/cl/148970043

Fixes #5551.
Fixes #4449.

Adds tests for both issues.

Note that the two issues occur only when formatting partial Go code
with indent.

The best way to understand the change is as follows: I took the code
of cmd/gofmt and go/format, combined it into one unified code that
does not suffer from either 4449 nor 5551, and then applied that code
to both cmd/gofmt and go/format.

As a result, there is now much more identical code between the two
packages, making future code deduplication easier (it was not possible
to do that now without adding public APIs, which I was advised not to
do at this time).

More specifically, I took the parse() of cmd/gofmt which correctly
preserves comments (issue 5551) and modified it to fix issue where
it would sometimes modify literal values (issue 4449).

I ended up removing the matchSpace() function because it no longer
needed to do some of its work (insert indent), and a part of its work
had to be done in advance (determining the indentation of first code
line), because that calculation is required for cfg.Fprint() to run.

adjustIndent is used to adjust the indent of cfg.Fprint() to compensate
for the body of wrapper func being indented by one level. This allows
to get rid of the bytes.Replace text manipulation of inner content,
which was problematic and sometimes altered raw string literals (issue
4449). This means that sometimes the value of cfg.Indent is negative,
but that works as expected.

So now the algorithm for formatting partial Go code is:

1. Determine and prepend leading space of original source.
2. Determine and prepend indentation of first code line.
3. Format and write partial Go code (with all of its leading &
   trailing space trimmed).
4. Determine and append trailing space of original source.

LGTM=gri
R=golang-codereviews, bradfitz, gri
CC=golang-codereviews
https://golang.org/cl/142360043