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>

Updates #10767

Change-Id: I197535f71bc2dc45e783f38d8031aa717d50fd80
Reviewed-on: https://go-review.googlesource.com/31733
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

For -newparser only.

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

Previously, the check to make sure we only considered constant cases
for duplicates was skipping past integer ranges, because those use
n.List instead of n.Left. Thanks to Emmanuel Odeke for investigating
and helping to identify the root cause.

Fixes #17517.

Change-Id: I46fcda8ed9c346ff3a9647d50b83f1555587b740
Reviewed-on: https://go-review.googlesource.com/31716
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>
Reviewed-by: Robert Griesemer <gri@golang.org>

Fixes #16428.

Change-Id: I78d37472e228402bb3c06d7ebd441952386fa38a
Reviewed-on: https://go-review.googlesource.com/31731
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>

Avoids some garbage allocations while loading import data. Seems to
especially benefit html/template for some reason, but significant
allocation improvements for other packages too.

name       old time/op     new time/op     delta
Template       345ms ± 6%      332ms ± 6%   -3.76%        (p=0.000 n=49+47)
Unicode        185ms ±10%      184ms ±12%     ~           (p=0.401 n=50+49)
GoTypes        1.04s ± 3%      1.04s ± 3%   -0.72%        (p=0.012 n=48+47)
Compiler       4.52s ± 7%      4.49s ± 9%     ~           (p=0.465 n=48+47)

name       old user-ns/op  new user-ns/op  delta
Template        532M ±17%       471M ±23%  -11.48%        (p=0.000 n=50+50)
Unicode         298M ±29%       311M ±28%     ~           (p=0.065 n=50+50)
GoTypes        1.52G ± 7%      1.54G ± 9%     ~           (p=0.062 n=49+50)
Compiler       6.37G ± 7%      6.42G ± 8%     ~           (p=0.157 n=49+48)

name       old alloc/op    new alloc/op    delta
Template      43.9MB ± 0%     42.3MB ± 0%   -3.51%        (p=0.000 n=48+48)
Unicode       34.3MB ± 0%     34.3MB ± 0%     ~           (p=0.945 n=50+50)
GoTypes        123MB ± 0%      122MB ± 0%   -0.82%        (p=0.000 n=50+50)
Compiler       522MB ± 0%      519MB ± 0%   -0.51%        (p=0.000 n=50+50)

name       old allocs/op   new allocs/op   delta
Template        414k ± 0%       397k ± 0%   -4.14%        (p=0.000 n=50+49)
Unicode         320k ± 0%       320k ± 0%     ~           (p=0.988 n=48+49)
GoTypes        1.18M ± 0%      1.17M ± 0%   -0.97%        (p=0.000 n=50+50)
Compiler       4.44M ± 0%      4.41M ± 0%   -0.66%        (p=0.000 n=50+50)

Passes toolstash.

Change-Id: I0f54c0fa420d4f4ed3584c47cec0dde100c70c03
Reviewed-on: https://go-review.googlesource.com/31670
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>

Only ASCII is permitted there.

Fixes #4385

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

This change updates the vendored copy of x/crypto/curve25519,
specifically to include the following changes:
  f620851 curve25519: eliminate unnecessary "callee save" prologues
  722a7b7 curve25519: fix confusing SP adjustments

Change-Id: I1b16aba12c744ac32f925654a136a8f52cd40fc2
Reviewed-on: https://go-review.googlesource.com/31666
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Adam Langley <agl@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Updates http2 to x/net/http2 git rev 40a0a18 for:

    http2: fix Server race with concurrent Read/Close
    http2: make Server reuse 64k request body buffer between requests
    http2: never Read from Request.Body in Transport to determine ContentLength

Fixes #17480
Updates #17071

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

Fixes #17532

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

The old wording over-promised.

Fixes #16957

Change-Id: Iaac04de0d24eb17a0db66beeeab9de70d0f6d391
Reviewed-on: https://go-review.googlesource.com/31735Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Tom Bergan <tombergan@google.com>

This partially reverts commit 01bf5cc2.

For unknown reasons, this CL was causing an internal test to allocate
1.2GB when it used to allocate less than 300MB.

Change-Id: I41d767781e0ae9e43bf670e2a186ee074821eca4
Reviewed-on: https://go-review.googlesource.com/31674Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>

With the old code rewriting refs would rewrite the inner arguments
rather than the outer ones, leaving a reference to C.val in the outer
arguments.

Change-Id: I9b91cb4179eccd08500d14c6591bb15acf8673eb
Reviewed-on: https://go-review.googlesource.com/31672
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>

This commit fixes two bizarrely related bugs:

1. The signatures for the call* functions were wrong, indicating that
they had only two pointer arguments instead of three. We didn't notice
because the call* functions are defined by a macro expansion, which go
vet doesn't see.

2. deferArgs on a defer object with a zero-sized frame returned a
pointer just past the end of the allocated object, which is illegal in
Go (and can cause the "sweep increased allocation count" crashes).

In a fascinating twist, these two bugs canceled each other out, which
is why I'm fixing them together. The pointer returned by deferArgs is
used in only two ways: as an argument to memmove and as an argument to
reflectcall. memmove is NOSPLIT, so the argument was unobservable.
reflectcall immediately tail calls one of the call* functions, which
are not NOSPLIT, but the deferArgs pointer just happened to be the
third argument that was accidentally marked as a scalar. Hence, when
the garbage collector scanned the stack, it didn't see the bad
pointer as a pointer.

I believe this was all ultimately benign. In principle, stack growth
during the reflectcall could fail to update the args pointer, but it
never points to the stack, so it never needs to be updated. Also in
principle, the garbage collector could fail to mark the args object
because of the incorrect call* signatures, but in all calls to
reflectcall (including the ones spelled "call" in the reflect package)
the args object is kept live by the calling stack.

Change-Id: Ic932c79d5f4382be23118fdd9dba9688e9169e28
Reviewed-on: https://go-review.googlesource.com/31654
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>

trace's reader *g is going to cause write barriers in unfortunate
places, so replace it with a guintptr.

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

There was some ambiguity over which argument was referred to when
a conversion error was returned. Now refer to the argument by
either explicit ordinal position or name if present.

Fixes #15676

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

The m5 and m6 fields were the wrong way round.

Fixes #17444.

Change-Id: I10297064f2cd09d037eac581c96a011358f70aae
Reviewed-on: https://go-review.googlesource.com/31130
Run-TryBot: Michael Munday <munday@ca.ibm.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>

Adapt old test for prove's bounds check elimination.
Added missing rule to generic rules that lead to differences
between 32 and 64 bit platforms on sliceopt test.
Added debugging to prove.go that was helpful-to-necessary to
discover that missing rule.
Lowered debugging level on prove.go from 3 to 1; no idea
why it was previously 3.

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

This exposes HuffmanOnly in zlib and gzip packages, which is currently
unavailable.

Change-Id: If5d103bbc8b5fce2f5d740fd103a235c5d1ed7cd
Reviewed-on: https://go-review.googlesource.com/31186Reviewed-by: Nigel Tao <nigeltao@golang.org>
Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com>
Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>