name       old s/op    new s/op    delta
LinkCmdGo   0.29 ± 5%   0.29 ± 8%  -2.60%   (p=0.000 n=97+98)

name       old MaxRSS  new MaxRSS  delta
LinkCmdGo   106k ± 4%   105k ± 3%  -1.00%  (p=0.000 n=100+99)

Change-Id: I75a1c3b24ea711a15a5d2eae026b70b97ee7bad4
Reviewed-on: https://go-review.googlesource.com/31030
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Michael Hudson-Doyle <michael.hudson@canonical.com>

Before go supported buildmode=shared ·f symbols used to be defined
only when they were used. In order to solve #11480 the strategy
was changed to have these symbols defined on declaration which is
less efficient and generates many unneeded symbols.
With this change the best strategy is chosen for each situation,
improving static linking time:

name            old s/op    new s/op    delta
LinkCmdCompile   0.27 ± 5%   0.25 ± 6%  -8.22%   (p=0.000 n=98+96)
LinkCmdGo        0.30 ± 6%   0.29 ± 8%  -5.03%   (p=0.000 n=95+99)

name            old MaxRSS  new MaxRSS  delta
LinkCmdCompile   107k ± 2%    98k ± 3%  -8.32%  (p=0.000 n=99+100)
LinkCmdGo        106k ± 3%   104k ± 3%  -1.94%  (p=0.000 n=99+100)

Change-Id: I965eeee30541e724fd363804adcd6fda10f965a4
Reviewed-on: https://go-review.googlesource.com/31031Reviewed-by: Michael Hudson-Doyle <michael.hudson@canonical.com>

In general, these functions cannot behave correctly when given a
hostname, because a hostname may represent multiple IP addresses, and
first(isIPv4) chooses at most one.

Updates #9334

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

Looking at the kernel sources, I don't see how this is possible.
But obviously it is. Just try again.

Fixes #17161.

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

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

The old code leaves garbages in a temporary directory because it
cannot remove the current working directory on windows.
The new code changes the directory before calling os.Remove.

Furthermore, the old code assumes that ioutil.TempDir (os.TempDir)
doesn't return a relative path nor an UNC path.
If it isn't the case, the new code calls t.Fatal earlier for preventing
ambiguous errors.

Finally, the old code reassigns the variable which is used by the defer
function. It could cause unexpected results, so avoid that.

Change-Id: I5fc3902059ecaf18dc1341ecc4979d1206034cd7
Reviewed-on: https://go-review.googlesource.com/31790
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>

Updates #15345

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

Change-Id: Ia86841cf84bc17ff6ecc6e5ac4cec86384a0da00
Reviewed-on: https://go-review.googlesource.com/31719Reviewed-by: Matthew Dempsky <mdempsky@google.com>

Requires -newparser=1.

For #17487.
For #16339.

Change-Id: I156fb0c0f8a97e8c72dbbfbd7fe821efee12b957
Reviewed-on: https://go-review.googlesource.com/31597Reviewed-by: Matthew Dempsky <mdempsky@google.com>

It appears to be a vestigial holding ground for bugs.
But we have an issue tracker, and #1909 is there and open.

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

CL 31468 added TestLookupNonLDH, which was failing on Plan 9,
because LookupHost was expecting to return errNoSuchHost
on DNS resolution failure, while Plan 9 returned the
"dns failure" string.

In the Plan 9 implementation of lookupHost, we now return
errNoSuchHost instead of the "dns failure" string, so
the behavior is more consistant with other operating systems.

Fixes #17568.

Change-Id: If64f580dc0626a4a4f19e5511ba2ca5daff5f789
Reviewed-on: https://go-review.googlesource.com/31873
Run-TryBot: David du Colombier <0intro@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Fixes #15557

Change-Id: I02ad98068894e75d4e08e271fdd16cb420519460
Reviewed-on: https://go-review.googlesource.com/31910Reviewed-by: Andrew Gerrand <adg@golang.org>

Change-Id: If061f1f120573cb109d97fa40806e160603cd593
Reviewed-on: https://go-review.googlesource.com/31871Reviewed-by: Rob Pike <r@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

VerifyPeerCertificate returns an error if the peer should not be
trusted. It will be called after the initial handshake and before
any other verification checks on the cert or chain are performed.
This provides the callee an opportunity to augment the certificate
verification.

If VerifyPeerCertificate is not nil and returns an error,
then the handshake will fail.

Fixes #16363

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

Fixes #17551.

Change-Id: I84b7d82654cda3559c119aa56b07f30d0d224865
Reviewed-on: https://go-review.googlesource.com/31857
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>

This prevents the traceback code from seeing a half-updated
stack frame when a profiling signal comes during the execution
of function prologue. Also fixes mips64x part of #17381.

Change-Id: Iec9683427e546e3648b2e8b1dde956d13f6eb938
Reviewed-on: https://go-review.googlesource.com/31721
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>

Since CL 30614, TestCloseError is failing on Plan 9,
because File.Write now checks f.fd == badFd before
calling syscall.Write.

The f.fd == badFd check returns os.ErrClosed, while
syscall.Write returned a syscall.ErrorString error.

TestCloseError was failing because it expected a
syscall.ErrorString error.

We add a case in parseCloseError to handle the
os.ErrClosed case.

Fixes #17569.

Change-Id: I6b4d956d18ed6d3c2ac5211ffd50a4888f7521e1
Reviewed-on: https://go-review.googlesource.com/31872
Run-TryBot: David du Colombier <0intro@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

OREGISTER is unused.

All remaining uses of Node.Reg use REGSP.

Change-Id: I51cf06826867e576baabd568e04f96d2634f5cad
Reviewed-on: https://go-review.googlesource.com/31856
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>

Crept into CL 9682, committed last week.

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

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

Fixes #16659

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

Adds a rule to generate ANDN for AND x ^y.

Fixes #17567

Change-Id: I3b978058d5663f32c42b1af19bb207eac5622615
Reviewed-on: https://go-review.googlesource.com/31769
Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>

The Gotype field is only used for ATYPE instructions. Instead of
specially storing the Go type symbol in From.Gotype, just store it in
To.Sym like any other 2-argument instruction would.

Modest reduction in allocations:

name       old alloc/op    new alloc/op    delta
Template      42.0MB ± 0%     41.8MB ± 0%  -0.40%         (p=0.000 n=9+10)
Unicode       34.3MB ± 0%     34.1MB ± 0%  -0.48%         (p=0.000 n=9+10)
GoTypes        122MB ± 0%      122MB ± 0%  -0.14%         (p=0.000 n=9+10)
Compiler       518MB ± 0%      518MB ± 0%  -0.04%         (p=0.000 n=9+10)

Passes toolstash -cmp.

Change-Id: I0e603266b5d7d4e405106a26369e22773a0d3a91
Reviewed-on: https://go-review.googlesource.com/31850
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Fixes issue golang/go#17563

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

Fixes #16309.

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

Leading spaces in a couple of lines instead of tabs cause those to be
misaligned (as seen on <https://golang.org/pkg/math/big/#Float.Parse>):

<<<
	number   = [ sign ] [ prefix ] mantissa [ exponent ] | infinity .
	sign     = "+" | "-" .
     prefix   = "0" ( "x" | "X" | "b" | "B" ) .
	mantissa = digits | digits "." [ digits ] | "." digits .
	exponent = ( "E" | "e" | "p" ) [ sign ] digits .
	digits   = digit { digit } .
	digit    = "0" ... "9" | "a" ... "z" | "A" ... "Z" .
     infinity = [ sign ] ( "inf" | "Inf" ) .
>>>

Replace the leading spaces with tabs so that those align well.

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

Fixes #17560

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

Change-Id: I22f0f3e792052762499f632571155768b4052bc9
Reviewed-on: https://go-review.googlesource.com/31759
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

This is clearer than syscall.EBADF.

Fixes #17320.

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

\\?\c:\ is a "root directory" that is not subject to further matching,
but the ? makes it look like a pattern, which was causing an
infinite recursion. Make sure the code understands the ? is not a pattern.

Fixes #15879.

Change-Id: I3a4310bbc398bcae764b9f8859c875317345e757
Reviewed-on: https://go-review.googlesource.com/31460Reviewed-by: Quentin Smith <quentin@golang.org>

RFC 3986 §3.3 disallows relative URL paths in which the first segment
contains a colon, presumably to avoid confusion with scheme:foo syntax,
which is exactly what happened in #16822.

Fixes #16822.

Change-Id: Ie4449e1dd21c5e56e3b126e086c3a0b05da7ff24
Reviewed-on: https://go-review.googlesource.com/31582Reviewed-by: Quentin Smith <quentin@golang.org>

Fixes #17181.

Change-Id: If7cc4865e391acf76512f7ec7167d5a31377b598
Reviewed-on: https://go-review.googlesource.com/31574Reviewed-by: Rob Pike <r@golang.org>

Change-Id: Ic6317f186d0ee68ab1f2d15be9a966a152f61bfb
Reviewed-on: https://go-review.googlesource.com/31610
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>

Fixed by CL 31092 already, but that change is a few steps away
from the problem observed here, so add an explicit test.

Fixes #17019.

Change-Id: If4ece1418e6596b1976961347889ce12c5969637
Reviewed-on: https://go-review.googlesource.com/31466
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Quentin Smith <quentin@golang.org>

All prior versions of Go have allowed redefining empty templates
to become non-empty. Unfortunately, that has never consistently
taken effect in html/template after the first execution:

	// define and execute
	t := template.New("root")
	t.Parse(`{{define "T"}}{{end}}<a href="{{template "T"}}">`)
	t.Execute(w, nil) // <a href="">

	// redefine
	t.Parse(`{{define "T"}}my.url{{end}}`) // succeeds, but ignored
	t.Execute(w, nil) // <a href="">

When Go 1.6 added {{block...}} to text/template, that loosened the
redefinition rules to allow redefinition at any time. The loosening was
undone a bit in html/template, although inconsistently:

	// define and execute
	t := template.New("root")
	t.Parse(`{{define "T"}}body{{end}}`)
	t.Lookup("T").Execute(ioutil.Discard, nil)

	// attempt to redefine
	t.Parse(`{{define "T"}}body{{end}}`) // rejected in all Go versions
	t.Lookup("T").Parse("body") // OK as of Go 1.6, likely unintentionally

Like in the empty->non-empty case, whether future execution takes
notice of a redefinition basically can't be explained without going into
the details of the template escape analysis.

Address both the original inconsistencies in whether a redefinition
would have any effect and the new inconsistencies about whether a
redefinition is allowed by adopting a new rule: no parsing or modifying
any templates after the first execution of any template in the same set.
Template analysis begins at first execution, and once template analysis
has begun, we simply don't have the right logic to update the analysis
for incremental modifications (and never have).

If this new rule breaks existing uses of templates that we decide need
to be supported, we can try to invalidate all escape analysis for the
entire set after any modifications. But let's wait on that until we know
we need to and why.

Also fix documentation of text/template redefinition policy
(redefinition is always OK).

Fixes #15761.

Change-Id: I7d58d7c08a7d9df2440ee0d651a5b2ecaff3006c
Reviewed-on: https://go-review.googlesource.com/31464
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Andrew Gerrand <adg@golang.org>

The Go resolver reports invalid domain name for '!!!.local',
but that is allowed by multicast DNS. In general we can't predict
what future relaxations might come along, and libc resolvers
do not distinguish 'no such host' from 'invalid name', so stop
making that distinction here too. Always use 'no such host'.

Fixes #12421.

Change-Id: I8f22604767ec9e270434e483da52b337833bad71
Reviewed-on: https://go-review.googlesource.com/31468
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>

Fixes #16959.

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

This is the documented (and now implemented) behavior.

Fixes #16841.

Change-Id: Ic75adc5ba18303ed9578e04284f32933f905d6a3
Reviewed-on: https://go-review.googlesource.com/31577Reviewed-by: Quentin Smith <quentin@golang.org>

Fixes #16564.

Change-Id: Idd7b3c8f1d8415acd952d1efb6dc35ba4191805d
Reviewed-on: https://go-review.googlesource.com/31578
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Quentin Smith <quentin@golang.org>

Fixes #16657.

Change-Id: I9425af91a48016b1d7465b9f43cafa792bc00bb3
Reviewed-on: https://go-review.googlesource.com/31581Reviewed-by: Quentin Smith <quentin@golang.org>