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>

If a directory in GOPATH is unreadable, we should keep looking for other
packages. Otherwise we can give the misleading error "no buildable Go
source files".

Fixes #16240

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

Fixes reported by oshimaya (see #13806).

Fixes #13806.

Change-Id: I9b659ab918a34bc5f7c58f3d7f59058115b7f776
Reviewed-on: https://go-review.googlesource.com/31651Reviewed-by: Minux Ma <minux@golang.org>

Fixes #15610.

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

What matters during go get -u is not whether there is an import comment
but whether we resolved the path by an HTML <meta> tag.

Fixes #16471.

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

Maybe the go generate is generating the imports,
or maybe there's some other good reason the code
is incomplete.

The help text already says:

	Note that go generate does not parse the file, so lines that look
	like directives in comments or multiline strings will be treated
	as directives.

We'll still reject Go source files that don't begin with a package statement
or have a syntax error in the import block, but those are I think more
defensible rejections.

Fixes #16307.

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

It's always been like this, so document it.

Fixes #14351.

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

Avoid crash in the specific case reported in #15201 but also
print more useful error message, avoiding slice panic.

Fixes #15201.
Fixes #16167.
Fixes #16566.

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

After resizing the scan buffer, we can immediately read into the
newly-resized buffer since we know there is now space.

Fixes #15712.

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

According to "Intel 64 and IA-32 Architectures Optimization Reference
Manual" Section: "3.5.1.13 Zero-Latency MOV Instructions"
MOV?ZX instructions have zero latency on newer processors.

during make.bash:
(ANDLconst [0xFF] x) -> (MOVBQZX x)
applies 422 times
(ANDLconst [0xFFFF] x) -> (MOVWQZX x)
applies 114 times

Updates #15105

Change-Id: I10933af599de3c26449c52f4b5cd859331028f39
Reviewed-on: https://go-review.googlesource.com/31639
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Run-TryBot: David Chase <drchase@google.com>

Makes windows same as others.

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

Currently mspan.isFree technically returns whether the object was not
allocated *during this cycle*. Fix it so it actually returns whether
or not the object is allocated so the method is more generally useful
(especially for debugging).

It has one caller, which is carefully written to be insensitive to
this distinction, but this lets us simplify this caller.

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

morestack writes the context pointer to gobuf.ctxt, but since
morestack is written in assembly (and has to be very careful with
state), it does *not* invoke the requisite write barrier for this
write. Instead, we patch this up later, in newstack, where we invoke
an explicit write barrier for ctxt.

This already requires some subtle reasoning, and it's going to get a
lot hairier with the hybrid barrier.

Fix this by simplifying the whole mechanism. Instead of writing
gobuf.ctxt in morestack, just pass the value of the context register
to newstack and let it write it to gobuf.ctxt. This is a normal Go
pointer write, so it gets the normal Go write barrier. No subtle
reasoning required.

Updates #17503.

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

Fixes #17159

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

Fixes #17504

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

So errnoErr can be used in other packages.
This is something I missed when I sent CL 28990.

Fixes #17539

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

This is an alternate solution to https://golang.org/cl/31445

Instead of making NewRequest return a request with Request.Body == nil
to signal a zero byte body, add a well-known variable that means
explicitly zero.

Too many tests inside Google (and presumably the outside world)
broke.

Change-Id: I78f6ecca8e8aa1e12179c234ccfb6bcf0ee29ba8
Reviewed-on: https://go-review.googlesource.com/31726
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com>

The test is broken on macOS Sierra.

Updates #17463.

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

This makes it possible to use URLs with gob.

Ideally we'd also implement TextMarshaler and TextUnmarshaler,
but that would change the JSON encoding of a URL from something like:

	{"Scheme":"https","Opaque":"","User":null,"Host":"www.google.com","Path":"/x","RawPath":"","ForceQuery":false,"RawQuery":"y=z","Fragment":""}

to something like:

	"https://www.google.com/x?y=z"

That'd be nice, but it would break code expecting the old form.

Fixes #10964.

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

Now that we have the Clone method on tls.Config, net/http doesn't need
any custom functions to do that any more.

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

According to the GNU manual, the format is:
<<<
GNU.sparse.size=size
GNU.sparse.numblocks=numblocks
repeat numblocks times
  GNU.sparse.offset=offset
  GNU.sparse.numbytes=numbytes
end repeat
>>>

The logic in parsePAX converts the repeating sequence of
(offset, numbytes) pairs (which is not PAX compliant) into a single
comma-delimited list of numbers (which is now PAX compliant).

Thus, we validate the following:
* The (offset, numbytes) headers must come in the correct order.
* The ',' delimiter cannot appear in the value.
We do not validate that the value is a parsible decimal since that
will be determined later.

Change-Id: I8d6681021734eb997898227ae8603efb1e17c0c8
Reviewed-on: https://go-review.googlesource.com/31439
Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Fixes #16003

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

Text from rsc.

Fixes #17093

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