go, branch go1.8.4

[release-branch.go1.8] go1.8.4

2017-10-04T18:39:32Z

Change-Id: Iae6c1ccd1e42656fa5a57d6367e43085143cd590 Reviewed-on: https://go-review.googlesource.com/68234 Reviewed-by: Russ Cox

[release-branch.go1.8] net/smtp: fix PlainAuth to refuse to send passwords to non-TLS servers

2017-10-04T18:19:06Z

PlainAuth originally refused to send passwords to non-TLS servers and was documented as such. In 2013, issue #5184 was filed objecting to the TLS requirement, despite the fact that it is spelled out clearly in RFC 4954. The only possibly legitimate use case raised was using PLAIN auth for connections to localhost, and the suggested fix was to let the server decide: if it advertises that PLAIN auth is OK, believe it. That approach was adopted in CL 8279043 and released in Go 1.1. Unfortunately, this is exactly wrong. The whole point of the TLS requirement is to make sure not to send the password to the wrong server or to a man-in-the-middle. Instead of implementing this rule, CL 8279043 blindly trusts the server, so that if a man-in-the-middle says "it's OK, you can send me your password," PlainAuth does. And the documentation was not updated to reflect any of this. This CL restores the original TLS check, as required by RFC 4954 and as promised in the documentation for PlainAuth. It then carves out a documented exception for connections made to localhost (defined as "localhost", "127.0.0.1", or "::1"). Cherry-pick of CL 68170. Change-Id: I1d3729bbd33aa2f11a03f4c000e6bb473164957b Reviewed-on: https://go-review.googlesource.com/68023 Run-TryBot: Russ Cox Reviewed-by: Chris Broadfoot

[release-branch.go1.8] cmd/go: reject update of VCS inside VCS

2017-10-04T18:15:44Z

Cherry-pick of CL 68110. Change-Id: Iae84c6404ab5eeb6950faa2364f97a017c67c506 Reviewed-on: https://go-review.googlesource.com/68190 Run-TryBot: Russ Cox Reviewed-by: Chris Broadfoot

[release-branch.go1.8] runtime: deflake TestPeriodicGC

2017-10-04T18:04:50Z

It was only waiting 0.1 seconds for the two GCs it wanted. Let it wait 1 second. Change-Id: Ib3cdc8127cbf95694a9f173643c02529a85063af Reviewed-on: https://go-review.googlesource.com/68150 Run-TryBot: Russ Cox Reviewed-by: Chris Broadfoot Reviewed-by: Austin Clements

[release-branch.go1.8] os: skip TestNetworkSymbolicLink if Server service is not started

2017-10-04T17:03:14Z

Fixes #20179 Change-Id: I2b405c9a212a75aae628ad51885616d33c054191 Reviewed-on: https://go-review.googlesource.com/42190 Reviewed-by: Brad Fitzpatrick Run-TryBot: Brad Fitzpatrick TryBot-Result: Gobot Gobot Reviewed-on: https://go-review.googlesource.com/68030 Run-TryBot: Chris Broadfoot Reviewed-by: Alex Brainman Reviewed-by: Ian Lance Taylor

[release-branch.go1.8] doc: update bootstrap archive URL

2017-05-31T21:06:00Z

This includes the patch for systems that build PIE executables by defaul Updates #20276. Change-Id: Iecf8dfcf11bc18d397b8075559c37e3610f825cb Reviewed-on: https://go-review.googlesource.com/44470 Reviewed-by: Ian Lance Taylor Reviewed-on: https://go-review.googlesource.com/44491 Reviewed-by: Chris Broadfoot

[release-branch.go1.8] go1.8.3

2017-05-24T18:14:11Z

Change-Id: I048f21f8ca68758fdd7ac875f7db5e4ed1930f3b Reviewed-on: https://go-review.googlesource.com/44037 Reviewed-by: Brad Fitzpatrick

[release-branch.go1.8] doc: document go1.8.3

2017-05-24T18:12:51Z

Change-Id: I5d55c3b1011dd10552d8e740fb65886306d91b5c Reviewed-on: https://go-review.googlesource.com/44035 Reviewed-by: Brad Fitzpatrick Reviewed-on: https://go-review.googlesource.com/44036

[release-branch.go1.8] cmd/compile: don't move spills to loop exits where the spill is dead

2017-05-24T15:44:39Z

We shouldn't move a spill to a loop exit where the spill itself is dead. The stack location assigned to the spill might already be reused by another spill at this point. The case we previously handled incorrectly is the one where the value being spilled is still live, but the spill itself is dead. Fixes #20472 Patching directly on the release branch because the spill moving code has already been rewritten for 1.9. (And it doesn't have this bug.) Change-Id: I26c5273dafd98d66ec448750073c2b354ef89ad6 Reviewed-on: https://go-review.googlesource.com/44033 Run-TryBot: Keith Randall TryBot-Result: Gobot Gobot Reviewed-by: Cherry Zhang

[release-branch.go1.8] cmd/compile: zero ambiguously live variables at VARKILLs

2017-05-24T15:23:47Z

This is a redo of CL 41076 backported to the 1.8 release branch. There were major conflicts, so I had to basically rewrite it again from scratch. The way Progs are allocated changed. Liveness analysis and Prog generation got reordered. Liveness analysis changed from running on gc.BasicBlock to ssa.Block. All that makes the logic quite a bit different. Please review carefully. From CL 41076: At VARKILLs, zero a variable if it is ambiguously live. After the VARKILL anything this variable references might be collected. If it were to become live again later, the GC will see references to already-collected objects. We don't know a variable is ambiguously live until very late in compilation (after lowering, register allocation, ...), so it is hard to generate the code in an arch-independent way. We also have to be careful not to clobber any registers. Fortunately, this almost never happens so performance is ~irrelevant. There are only 2 instances where this triggers in the stdlib. Fixes #20029 Change-Id: Ibb757eec58ee07f40df5e561b19d315684dc4bda Reviewed-on: https://go-review.googlesource.com/43998 Run-TryBot: Keith Randall TryBot-Result: Gobot Gobot Reviewed-by: Matthew Dempsky