go, branch go1.7.3

[release-branch.go1.7] go1.7.3

2016-10-19T17:04:39Z

Change-Id: I906070c84c0f40c4dd8af8b5894895127834ee00 Reviewed-on: https://go-review.googlesource.com/31438 Run-TryBot: Chris Broadfoot TryBot-Result: Gobot Gobot Reviewed-by: Brad Fitzpatrick

[release-branch.go1.7] doc: document go1.7.3 and add note to go1.7.2 that it should not be used

2016-10-19T17:04:17Z

Change-Id: I3dd1513e927733ce5c63928da772cb81760ba869 Reviewed-on: https://go-review.googlesource.com/31442 Reviewed-by: Andrew Gerrand Reviewed-by: Brad Fitzpatrick

[release-branch.go1.7] net/http: update bundled http2

2016-10-19T00:01:52Z

Updates bundled http2 for x/net/http2 git rev d4c55e66 for: [release-branch.go1.7] http2: never Read from Request.Body in Transport to determine ContentLength https://golang.org/cl/31361 Updates #17480 Updates #17071 Change-Id: I2231adaed3cb5b368927a9654dcf7e69a8b664b6 Reviewed-on: https://go-review.googlesource.com/31432 Run-TryBot: Chris Broadfoot TryBot-Result: Gobot Gobot Reviewed-by: Chris Broadfoot

[release-branch.go1.7] net/http: update test to check Content-Length 0 Body more reliably

2016-10-18T23:50:01Z

The way to send an explicitly-zero Content-Length is to set a nil Body. Fix this test to do that, rather than relying on type sniffing. Updates #17480 Updates #17071 Change-Id: I6a38e20f17013c88ec4ea69d73c507e4ed886947 Reviewed-on: https://go-review.googlesource.com/31434 TryBot-Result: Gobot Gobot Run-TryBot: Brad Fitzpatrick Reviewed-by: Chris Broadfoot Reviewed-on: https://go-review.googlesource.com/31437 Run-TryBot: Chris Broadfoot

[release-branch.go1.7] go1.7.2

2016-10-17T21:08:12Z

Change-Id: I546e8b1aa4facdbf13bb80d386bf4839a3aff9d1 Reviewed-on: https://go-review.googlesource.com/31314 Run-TryBot: Chris Broadfoot TryBot-Result: Gobot Gobot Reviewed-by: Chris Broadfoot

[release-branch.go1.7] doc: document go1.7.2

2016-10-17T20:41:45Z

Change-Id: I34b3650ee9512879ff7528336813a7850c46ea90 Reviewed-on: https://go-review.googlesource.com/31311 Reviewed-by: Brad Fitzpatrick Reviewed-on: https://go-review.googlesource.com/31313 Reviewed-by: Chris Broadfoot

[release-branch.go1.7] crypto/{aes,cipher}: fix panic in CBC on s390x when src length is 0

2016-10-17T20:25:13Z

Adds a test to check that block cipher modes accept a zero-length input. Fixes #17435. Change-Id: Ie093c4cdff756b5c2dcb79342e167b3de5622389 Reviewed-on: https://go-review.googlesource.com/31070 Run-TryBot: Michael Munday TryBot-Result: Gobot Gobot Reviewed-by: Brad Fitzpatrick Reviewed-on: https://go-review.googlesource.com/31291 Reviewed-by: Michael Munday Run-TryBot: Chris Broadfoot

[release-branch.go1.7] cmd/compile: escape analysis needs to run "flood" to fixed point

2016-10-17T20:25:07Z

In some cases the members of the root set from which flood runs themselves escape, without their referents being also tagged as escaping. Fix this by reflooding from those roots whose escape increases, and also enhance the "leak" test to include reachability from a heap-escaped root. Fixes #17318. Change-Id: Ied1e75cee17ede8ca72a8b9302ce8201641ec593 Reviewed-on: https://go-review.googlesource.com/30693 Run-TryBot: David Chase TryBot-Result: Gobot Gobot Reviewed-by: Russ Cox Reviewed-on: https://go-review.googlesource.com/31290 Reviewed-by: Brad Fitzpatrick Reviewed-by: David Chase

[release-branch.go1.7] runtime: sleep on CLOCK_MONOTONIC in futexsleep1 on freebsd

2016-10-17T20:25:00Z

In FreeBSD 10.0, the _umtx_op syscall was changed to allow sleeping on any supported clock, but the default clock was switched from a monotonic clock to CLOCK_REALTIME. Prior to 10.0, the __umtx_op_wait* functions ignored the fourth argument to _umtx_op (uaddr1), expected the fifth argument (uaddr2) to be a struct timespec pointer, and used a monotonic clock (nanouptime(9)) for timeout calculations. Since 10.0, if callers want a clock other than CLOCK_REALTIME, they must call _umtx_op with uaddr1 set to a value greater than sizeof(struct timespec), and with uaddr2 as pointer to a struct _umtx_time, rather than a timespec. Callers can set the _clockid field of the struct _umtx_time to request the clock they want. The relevant FreeBSD commit: https://svnweb.freebsd.org/base?view=revision&revision=232144 Fixes #17168 Change-Id: I3dd7b32b683622b8d7b4a6a8f9eb56401bed6bdf Reviewed-on: https://go-review.googlesource.com/30154 Reviewed-by: Ian Lance Taylor Run-TryBot: Ian Lance Taylor TryBot-Result: Gobot Gobot Reviewed-on: https://go-review.googlesource.com/31269

[release-branch.go1.7] crypto/tls: fix deadlock when racing to complete handshake.

2016-10-17T20:24:52Z

After renegotiation support was added (af125a5193c) it's possible for a Write to block on a Read when racing to complete the handshake: 1. The Write determines that a handshake is needed and tries to take the neccesary locks in the correct order. 2. The Read also determines that a handshake is needed and wins the race to take the locks. 3. The Read goroutine completes the handshake and wins a race to unlock and relock c.in, which it'll hold when waiting for more network data. If the application-level protocol requires the Write to complete before data can be read then the system as a whole will deadlock. Unfortunately it doesn't appear possible to reverse the locking order of c.in and handshakeMutex because we might read a renegotiation request at any point and need to be able to do a handshake without unlocking. So this change adds a sync.Cond that indicates that a goroutine has committed to doing a handshake. Other interested goroutines can wait on that Cond when needed. The test for this isn't great. I was able to reproduce the deadlock with it only when building with -race. (Because -race happened to alter the timing just enough.) Fixes #17101. Change-Id: I4e8757f7b82a84e46c9963a977d089f0fb675495 Reviewed-on: https://go-review.googlesource.com/29164 Reviewed-by: Brad Fitzpatrick Reviewed-by: Ian Lance Taylor Reviewed-on: https://go-review.googlesource.com/31268