When using a stack-allocated buffer for the result, don't
expose the uninitialized portion of it by restricting its
capacity to its length.

The other option is to zero the portion between len and cap.
That seems like more work, but might be worth it if the caller
then appends some stuff to the result.  But this close to 1.6,
I'm inclined to do the simplest fix possible.

Fixes #14232

Change-Id: I21c50d3cda02fd2df4d60ba5e2cfe2efe272f333
Reviewed-on: https://go-review.googlesource.com/19231Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

The plan9.bell-labs.com site has fallen into disrepair.
We'll instead use the site maintained by contributor David du Colombier.

Fixes #14233

Change-Id: I0c702e5d3b091cccd42b288ea32f34d507a4733d
Reviewed-on: https://go-review.googlesource.com/19240Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: David du Colombier <0intro@gmail.com>

Update #14063.

Change-Id: Id13456deb15c90a8af282b77d78ff5cdbd1de8bf
Reviewed-on: https://go-review.googlesource.com/19208
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Minux Ma <minux@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Fixes #14219.

Change-Id: Id398dcfe6e9978d7eefddcdaaaa2256c16237cf3
Reviewed-on: https://go-review.googlesource.com/19207
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Minux Ma <minux@golang.org>

libcurl sends this (despite never being standardized), and the Google
GFE rejects it with a 400 bad request (but only when over http2?).

So nuke it.

Change-Id: I3fc95523d50f33a0e23bb26b9195f70ab0aed0f4
Reviewed-on: https://go-review.googlesource.com/19184Reviewed-by: Chris Broadfoot <cbro@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>

Previous flakes:
https://build.golang.org/log/223365dedb6b6aa0cfdf5afd0a50fd433a16bade
https://build.golang.org/log/edbea4cd3f24e707ef2ae8378559bb0fcc453c22

Dmitry says in email about this:

> The stack trace points to it pretty clearly. Done can indeed unblock
> Wait first and then panic. I guess we need to recover after first
> Done as well.

And it looks like TestWaitGroupMisuse2 was already hardened against
this.  Do the same in TestWaitGroupMisuse3.

Change-Id: I317800c7e46f13c97873f0873c759a489dd5f47d
Reviewed-on: https://go-review.googlesource.com/19183Reviewed-by: Dmitry Vyukov <dvyukov@google.com>
Reviewed-by: Austin Clements <austin@google.com>
Reviewed-by: Russ Cox <rsc@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

The loading of zversion.go was expecting it to be in
package runtime, but it moved to runtime/internal/sys.
Worse, the load was not checking the error.

Update the path, check the error, add a test.

Fixes #14176.

Change-Id: I203c40afe1448875581415d5e42c29f09b14545d
Reviewed-on: https://go-review.googlesource.com/19180
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Fixes #14201.

Change-Id: Ib61f8c00cae72463f59b90ae199fbdc1e7422a79
Reviewed-on: https://go-review.googlesource.com/19174
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Michael Hudson-Doyle <michael.hudson@canonical.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>

Fixes #14202

Change-Id: Ia6dccecb1b9b3f6c0838c99090e6ddf1ad43303c
Reviewed-on: https://go-review.googlesource.com/19175
Run-TryBot: Rob Pike <r@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>

Fixes #14171.

Change-Id: Ie75c1cfd88801618308d472bc04e7fc648c95e0c
Reviewed-on: https://go-review.googlesource.com/19150Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Updates #13841

Change-Id: I121bce054e2756c820c76444e51357f474b7f3d6
Reviewed-on: https://go-review.googlesource.com/19161Reviewed-by: Russ Cox <rsc@golang.org>

RFC Errata 4522 (http://www.rfc-editor.org/errata_search.php?eid=4522)
notes that RFC 2616 had a typo in a list of headers that the
httputil.ReverseProxy code copied. Fix the typo in our code.

Fixes #14174

Change-Id: Ifc8f18fd58a6508a02a23e54ff3c473f03e521d3
Reviewed-on: https://go-review.googlesource.com/19133Reviewed-by: Russ Cox <rsc@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Fixes #14195

Change-Id: I245b3ca3fd7d1a76aa95f2e058f8432ba5ce31ee
Reviewed-on: https://go-review.googlesource.com/19160
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Reviewed-by: Russ Cox <rsc@golang.org>

This corrects a regression from Go 1.5 introduced by CL 18317.

Fixes #14185.

Change-Id: Ic3215714846d9f28809cd04e3eb3664b599244f4
Reviewed-on: https://go-review.googlesource.com/19151Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Tested manually with "go test -run TestGetSubmodules".

Fixes #14194.

Change-Id: I4f563b2b8a38f3040d7631f74a7908ab65e0860b
Reviewed-on: https://go-review.googlesource.com/19154Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Failed at https://storage.googleapis.com/go-build-log/9875de36/nacl-amd64p32_931ba6cf.log

Change-Id: I2bc204ed58da543ee2534b69c29c8e8485d54683
Reviewed-on: https://go-review.googlesource.com/19155
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Currently it's possible for the scheduler to deadlock with the right
confluence of locked Gs, assists, and scheduling of background mark
workers. Broadly, this happens because handoffp is stricter than
findrunnable, and if the only work for a P is GC work, handoffp will
put the P into idle, rather than starting an M to execute that P. One
way this can happen is as follows:

0. There is only one user G, which we'll call G 1. There is more than
   one P, but they're all idle except the one running G 1.

1. G 1 locks itself to an M using runtime.LockOSThread.

2. GC starts up and enters mark 1.

3. G 1 performs a GC assist, which completes mark 1 without being
   fully satisfied. Completing mark 1 causes all background mark
   workers to park. And since the assist isn't fully satisfied, it
   parks as well, waiting for a background mark worker to satisfy its
   remaining assist debt.

4. The assist park enters the scheduler. Since G 1 is locked to the M,
   the scheduler releases the P and calls handoffp to hand the P to
   another M.

5. handoffp checks the local and global run queues, which are empty,
   and sees that there are idle Ps, so rather than start an M, it puts
   the P into idle.

At this point, all of the Gs are waiting and all of the Ps are idle.
In particular, none of the GC workers are running, so no mark work
gets done and the assist on the main G is never satisfied, so the
whole process soft locks up.

Fix this by making handoffp start an M if there is GC work. This
reintroduces a key invariant: that in any situation where findrunnable
would return a G to run on a P, handoffp for that P will start an M to
run work on that P.

Fixes #13645.

Tested by running 2,689 iterations of `go tool dist test -no-rebuild
runtime:cpu124` across 10 linux-amd64-noopt VMs with no failures.
Without this change, the failure rate was somewhere around 1%.

Performance change is negligible.

name              old time/op  new time/op  delta
XBenchGarbage-12  2.48ms ± 2%  2.48ms ± 1%  -0.24%  (p=0.000 n=92+93)

name                      old time/op    new time/op    delta
BinaryTree17-12              2.86s ± 2%     2.87s ± 2%    ~     (p=0.667 n=19+20)
Fannkuch11-12                2.52s ± 1%     2.47s ± 1%  -2.05%  (p=0.000 n=18+20)
FmtFprintfEmpty-12          51.7ns ± 1%    51.5ns ± 3%    ~     (p=0.931 n=16+20)
FmtFprintfString-12          170ns ± 1%     168ns ± 1%  -0.65%  (p=0.000 n=19+19)
FmtFprintfInt-12             160ns ± 0%     160ns ± 0%  +0.18%  (p=0.033 n=17+19)
FmtFprintfIntInt-12          265ns ± 1%     273ns ± 1%  +2.98%  (p=0.000 n=17+19)
FmtFprintfPrefixedInt-12     235ns ± 1%     239ns ± 1%  +1.99%  (p=0.000 n=16+19)
FmtFprintfFloat-12           315ns ± 0%     315ns ± 1%    ~     (p=0.250 n=17+19)
FmtManyArgs-12              1.04µs ± 1%    1.05µs ± 0%  +0.87%  (p=0.000 n=17+19)
GobDecode-12                7.93ms ± 0%    7.85ms ± 1%  -1.03%  (p=0.000 n=16+18)
GobEncode-12                6.62ms ± 1%    6.58ms ± 1%  -0.60%  (p=0.000 n=18+19)
Gzip-12                      322ms ± 1%     320ms ± 1%  -0.46%  (p=0.009 n=20+20)
Gunzip-12                   42.5ms ± 1%    42.5ms ± 0%    ~     (p=0.751 n=19+19)
HTTPClientServer-12         69.7µs ± 1%    70.0µs ± 2%    ~     (p=0.056 n=19+19)
JSONEncode-12               16.9ms ± 1%    16.7ms ± 1%  -1.13%  (p=0.000 n=19+19)
JSONDecode-12               61.5ms ± 1%    61.3ms ± 1%  -0.35%  (p=0.001 n=20+17)
Mandelbrot200-12            3.94ms ± 0%    3.91ms ± 0%  -0.67%  (p=0.000 n=20+18)
GoParse-12                  3.71ms ± 1%    3.70ms ± 1%    ~     (p=0.244 n=17+19)
RegexpMatchEasy0_32-12       101ns ± 1%     102ns ± 2%  +0.54%  (p=0.037 n=19+20)
RegexpMatchEasy0_1K-12       349ns ± 0%     350ns ± 0%  +0.33%  (p=0.000 n=17+18)
RegexpMatchEasy1_32-12      84.5ns ± 2%    84.2ns ± 1%  -0.43%  (p=0.048 n=19+20)
RegexpMatchEasy1_1K-12       510ns ± 1%     513ns ± 2%  +0.58%  (p=0.002 n=18+20)
RegexpMatchMedium_32-12      132ns ± 1%     134ns ± 1%  +0.95%  (p=0.000 n=20+20)
RegexpMatchMedium_1K-12     40.1µs ± 1%    39.6µs ± 1%  -1.39%  (p=0.000 n=20+20)
RegexpMatchHard_32-12       2.08µs ± 0%    2.06µs ± 1%  -0.95%  (p=0.000 n=18+18)
RegexpMatchHard_1K-12       62.2µs ± 1%    61.9µs ± 1%  -0.42%  (p=0.001 n=19+20)
Revcomp-12                   537ms ± 0%     536ms ± 0%    ~     (p=0.076 n=20+20)
Template-12                 71.3ms ± 1%    69.3ms ± 1%  -2.75%  (p=0.000 n=20+20)
TimeParse-12                 361ns ± 0%     360ns ± 1%    ~     (p=0.056 n=19+19)
TimeFormat-12                353ns ± 0%     352ns ± 0%  -0.23%  (p=0.000 n=17+18)
[Geo mean]                  62.6µs         62.5µs       -0.17%

Change-Id: I0fbbbe4d7d99653ba5600ffb4394fa03558bc4e9
Reviewed-on: https://go-review.googlesource.com/19107Reviewed-by: Rick Hudson <rlh@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Updates x/net/http2 to git rev 644ffc for three CLs since the last update:

http2: don't add *Response to activeRes in Transport on Headers.END_STREAM
https://golang.org/cl/19134

http2: add mechanism to send undeclared Trailers mid handler
https://golang.org/cl/19131

http2: remove unused variable
https://golang.org/cl/18936

The first in the list above is the main fix that's necessary. The
other are two are in the git history but along for the cmd/bundle
ride. The middle CL is well-tested, small (mostly comments),
non-tricky, and almost never seen (since nobody really uses Trailers).
The final CL is just deleting an unused global variable.

Fixes #14084 again (with more tests)

Change-Id: Iac51350acee9c51d32bf7779d57e9d5a5482b928
Reviewed-on: https://go-review.googlesource.com/19135
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Andrew Gerrand <adg@golang.org>

Tested by hand with a runtime/cgo modified to return an mmap failure
after 10 calls.

This is an interim patch.  For 1.7 we should fix mmap properly to avoid
using the same value as both a pointer and an errno value.

Fixes #14149.

Change-Id: I8f2bbd47d711e283001ba73296f1c34a26c59241
Reviewed-on: https://go-review.googlesource.com/19084
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>

Fixes #14164.

Change-Id: Ib1d1d29674c99cf88e0ae12724823a31f5dbb95c
Reviewed-on: https://go-review.googlesource.com/19087
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>

Fixes #14146

Change-Id: I892ca4ccdc1ba785750e1eae800852dc5825156c
Reviewed-on: https://go-review.googlesource.com/19093Reviewed-by: Russ Cox <rsc@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>

This CL expands symlinks only when an error would be reported otherwise.
Since the expansions are only on error paths, anything that worked yesterday
should still work after this CL.

This CL fixes a regression from Go 1.5 in "go run", or else we'd probably
postpone it.

Changing only the error paths is meant as a way to reduce the risk of
making this change so late in the release cycle, but it may actually be
the right strategy for symlinks in general.

Fixes #14054.

Change-Id: I42ed1276f67a0c395297a62bcec7d36c14c06404
Reviewed-on: https://go-review.googlesource.com/19102
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Given, say, var f *os.File, a new vet check in CL 14122 diagnoses:

	fmt.Printf("%s\n", f.Name)
	fmt.Println(f.Name)

but not

	fmt.Printf("%v\n", f.Name)

In all three cases the error is that the argument should be f.Name().

Diagnosing Println but not Printf %v seems oddly inconsistent,
so I changed %v to have the check too. In fact, all verbs now have
the check except %p and %T.

Fixes Dave Cheney's confusion when trying to write an example
of the new vet check advertised in the Go 1.6 release notes.

Change-Id: I92fa6a7a1d5d9339a6a59ae4e587a254e633f500
Reviewed-on: https://go-review.googlesource.com/19101
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Rob Pike <r@golang.org>

Fixes #14124.

Change-Id: I9a694c402e613d27701e7e41640af357c373edea
Reviewed-on: https://go-review.googlesource.com/18959Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Fixes #14143

Change-Id: I2d77e55bc0b6bb42e11de291e0ddb5ad5d620646
Reviewed-on: https://go-review.googlesource.com/19110Reviewed-by: Russ Cox <rsc@golang.org>

Change-Id: Ib669d5241372326a46361ee096570e960b7a957f
Reviewed-on: https://go-review.googlesource.com/19082Reviewed-by: Ian Lance Taylor <iant@golang.org>

From twitter bug report: https://twitter.com/ox/status/692737249411207168

Change-Id: Ic5f4eeb00d705217542db558edc25e206f6b640d
Reviewed-on: https://go-review.googlesource.com/19050Reviewed-by: Russ Cox <rsc@golang.org>

We might be forwarding to a C signal handler.  C code expects the stack
to be aligned.  Should fix darwin/386 build: the testcarchive tests were
hanging as the program got an endless series of SIGSEGV signals.

Change-Id: Ia02485d3736a3c40e12259f02d25f842cf8e4d29
Reviewed-on: https://go-review.googlesource.com/19025
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

It's awkward to get a string value in cgoCheckArg, but SWIG testing
revealed that it is possible.  The new handling of extra files in the
ptr.go test emulates what SWIG does with an exported function that
returns a string.

Change-Id: I453717f867b8a49499576c28550e7c93053a0cf8
Reviewed-on: https://go-review.googlesource.com/19020
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>

It doesn't work there ("out of memory") and doesn't really matter.
Fixes build (now that we enable cgo on the darwin/386 builder.)

Change-Id: I1d91e51ecb88c54eae39ac9a76f2c0b4e45263b0
Reviewed-on: https://go-review.googlesource.com/19004
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Fixes #14107.

Change-Id: Icd9463b1a77b139c7ebc2d8732482d704ea332d0
Reviewed-on: https://go-review.googlesource.com/19002Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Followup to CL 19001.

Change-Id: I7fa838b1ee8df53229e9dd29a231c2f9b2aa3f69
Reviewed-on: https://go-review.googlesource.com/19003Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

It's causing the darwin-386 builder to fail with:

--- FAIL: TestDynlink (0.07s)
    obj6_test.go:118: error exit status 3 output go tool: no such tool "asm"
FAIL
FAIL    cmd/internal/obj/x86    0.073s

So skip it for now. It's tested in enough other places.

Change-Id: I9a98ad7b8be807005750112d892ac6c676c17dd5
Reviewed-on: https://go-review.googlesource.com/18989
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>

This makes "CGO_ENABLED=0 go list runtime/cgo" work,
which fixes the current cmd/go test failure.

Change-Id: Ia55ce3ba1dbb09f618ae5f4c8547722670360f59
Reviewed-on: https://go-review.googlesource.com/19001
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

We set GOMAXPROCS=1 to prevent test flakiness.
There are two sources of flakiness:
1. Some tests rely on particular execution order.
   If the order is different, race does not happen at all.
2. Ironically, ThreadSanitizer runtime contains a logical race condition
   that can lead to false negatives if racy accesses happen literally at the same time.
Tests used to work reliably in the good old days of GOMAXPROCS=1.
So let's set it for now. A more reliable solution is to explicitly annotate tests
with required execution order by means of a special "invisible" synchronization primitive
(that's what is done for C++ ThreadSanitizer tests). This is issue #14119.

This reduces flakes on RaceAsFunc3 test from 60/3000 to 1/3000.

Fixes #14086
Fixes #14079
Fixes #14035

Change-Id: Ibaec6b2b21e27b62563bffbb28473a854722cf41
Reviewed-on: https://go-review.googlesource.com/18968Reviewed-by: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

CL 18964 included an extra patch (sorry, my first experience of
git-codereview) which defined the conventional breakpoint instruction
used by Plan 9 on arm, but also introduced a benign but unneeded
call to runtime.emptyfunc.  This CL removes the redundant call again.

This completes the series of CLs which add support for Plan 9 on arm.

Change-Id: Id293cfd40557c9d79b4b6cb164ed7ed49295b178
Reviewed-on: https://go-review.googlesource.com/19010Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Also fix a few bad links.

Change-Id: If04cdd312db24a827a3c958a9974c50ab148656c
Reviewed-on: https://go-review.googlesource.com/18979Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

The vendored copy of golang.org/x/net/http/hpack was being treated
as not standard, which in turn was making it not subject to the mtime
exception for rebuilding the standard library in a release, which in turn
was making net/http look out of date.

One fix and three tests:

- Fix the definition of standard.
- Test that everything in $GOROOT/src/ is standard during 'go test cmd/go'.
(In general there can be non-standard things in $GOROOT/src/, but this
test implies that you can do that or you can run 'go test cmd/go',
but not both. That's fine.)
- Test that 'go list std cmd' shows our vendored code.
- Enforce that no standard package can depend on a non-standard one.

Also fix a few error printing nits.

Fixes #13713.

Change-Id: I1f943f1c354174c199e9b52075c11ee44198e81b
Reviewed-on: https://go-review.googlesource.com/18978Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>

Change-Id: I595379d2f02b0a43735f0375758e4997ce3b64a7
Reviewed-on: https://go-review.googlesource.com/18986
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Change-Id: Ibba7fccba9617612e026bd0a208eb12918de465a
Reviewed-on: https://go-review.googlesource.com/18985Reviewed-by: Russ Cox <rsc@golang.org>