Go 1.6 significantly improves pause times for large heaps, but it
improves them in many other situations as well, such as when goroutine
churn is high, allocation rate is high, or when there are many
finalizers. Hence, make the statement about pause times a bit more
general.

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

Currently we use "Section's" as the plural of the debug/elf Section
struct. Change this to "Sections" because it's not possessive and
doesn't seem to fall in to any special cases were the apostrophe is
acceptable.

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

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

Updates x/net/http2 to git rev 62685c2 for https://golang.org/cl/19483

Change-Id: Id01331cdba03934a6e55e55ad9c2ae27461ba149
Reviewed-on: https://go-review.googlesource.com/19484Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Type switches need write barriers if the written-to
variable is heap allocated.

For the added needwritebarrier call, the right arg doesn't
really matter, I just pass something that will never disqualify
the write barrier.  The left arg is the one that matters.

Fixes #14306

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

The code in mem_bsd.go expects that when mmap fails it will return a
positive errno value.  This fixes the Solaris implementation of mmap to
work as expected.

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

Fixes #14278

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

The caller of mmap expects it to return a positive errno value, but the
linux-arm64 and nacl-386 system calls returned a negative errno value.
Correct them to negate the errno value.

The caller of mincore expects it to return a negative errno value (yes,
this is inconsistent), but the linux-mips64x and linux-ppc64x system
call returned a positive errno value.  Correct them to negate the errno
value.

Add a test that mmap returns errno with the correct sign.  Brad added a
test for mincore's errno value in https://golang.org/cl/19457.

Fixes #14297.

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

Updates #14297

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

httptest.Server was rewritten during Go 1.6, but
CloseClientConnections was accidentally made async in the rewrite and
not caught due to lack of tests.

Restore the Go 1.5 behavior and add tests.

Fixes #14290
Updates #14291

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

1) go/types.dir: Correctly return "." if there is no path.
2) go/internal/gcimporter.FindPkg: work-around for build.Import
   (build.Import doesn't produce expected result if srcDir is
   relative). See also issue 14282.

Fixes #14215.

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

The Windows 7 getmac command may report the physical address of an adapter
as "Disabled" or "N/A". Handle these two cases to make the tests more
robust when building on Windows with manually disabled adapters or turned
off hardware.

Addresses issue #14130.

Change-Id: I0c2f8554b4b6810568e4e60ed53857599401f296
Reviewed-on: https://go-review.googlesource.com/19411Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Run-TryBot: Alex Brainman <alex.brainman@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>

For now, don't enable http2 when Transport.TLSConfig != nil.
See background in #14275.

Also don't enable http2 when ExpectContinueTimeout is specified for
now, in case somebody depends on that functionality. (It is not yet
implemented in http2, and was only just added to net/http too in Go
1.6, so nobody would be setting it yet).

Updates #14275
Updates #13851

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

Given GOPATH=p1:p2 and source code of just the right form,
the go command could previously end up invoking the compiler
with -I p2 -I p1 or the linker with -L p2 -L p1, so that
compiled packages in p2 incorrectly shadowed packages in p1.
If foo were in both p1 and p2 and the compilation of bar
were such that the -I and -L options were inverted in this way,
then

	GOPATH=p2 go install foo
	GOPATH=p1:p2 go install bar

would get the p2 copy of foo instead of the (expected) p1 copy of foo.

This manifested in real usage in a few different ways, but in all
the root cause was that the -I or -L option sequence did not
match GOPATH.

Make it match GOPATH.

Fixes #14176 (second report).
Fixes #14192.
Related but less common issue #14271 not fixed.

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

And update two imports in cmd/internal/objfile/disasm.go.
This makes GO15VENDOREXPERIMENT=0 ./make.bash work.
For Go 1.7 we will move it back.

Fixes #14236.

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

This error only affects the compilation of the standard library,
but I discovered that if you import "notexist" from the standard
library then you get both an error about notexist not existing
and an error about notexist being a non-standard package
(because the non-existant package is in fact not a standard package).
Silence the second error.

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

ListenAndServeTLS doesn't require cert and key file names if the
server's TLSConfig has a cert configured. This code was never updated
when the GetCertificate hook was added to *tls.Config, however.

Fixes #14268

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

Fixes #14262.

Change-Id: Id590995dd4460e81f6b91bcfb3f02515a97650fe
Reviewed-on: https://go-review.googlesource.com/19361
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Alan Donovan <adonovan@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Fixes #14259

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

The operation where this manifested in a crash was % (only defined on integers).
However, the existing code was sloppy in that it didn't retain the integer form
after a value (e.g., 3.0) was accepted as representable in integer form (3 for
the example). We would have seen a crash in such cases for / as well except
that there was code to fix it for just that case.

Remove the special code for / and fix more generally by retaining the integer
form for all operations if applicable.

Fixes #14229.

Change-Id: I8bef769e6299839fade27c6e8b5ff29ad6521d0d
Reviewed-on: https://go-review.googlesource.com/19300Reviewed-by: Alan Donovan <adonovan@google.com>

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

The test sends two HTTP/1.1 pipelined requests.  The first is
completedly by the second, and as such triggers an immediate call to the
CloseNotify channel.  The second calls the CloseNotify channel after the
overall connection is closed.

The test was passing fine on gc because the code would enter the select
loop before running the handler, so the send on gotReq would always be
seen first.  On gccgo the code would sometimes enter the select loop
after the handler had already finished, meaning that the select could
choose between gotReq and sawClose.  If it picked sawClose, it would
never close the overall connection, and the httptest server would hang.
The same hang could be induced with gc by adding a time.Sleep
immediately before the select loop.

Deflake the test by 1) don't close the overall connection until both
requests have been seen; 2) don't exit the loop until both closes have
been seen.

Fixes #14231.

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

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

Updates x/net/http2 to git rev 493a262 for https://golang.org/cl/19223

Fixes #14227

Change-Id: I626122811138fb3d88e4eea83f8da3fdcf91e0dc
Reviewed-on: https://go-review.googlesource.com/19250Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Updates #14227

Change-Id: If39f11471ecd307c9483f64e73f9c89fe906ae71
Reviewed-on: https://go-review.googlesource.com/19222Reviewed-by: Andrew Gerrand <adg@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>

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>