Convert splitUSTARPath to return a bool rather than an error since
the caller never ever uses the error other than to check if it is
nil. Thus, we can remove errNameTooLong as well.

Also, fold the checking of the length <= fileNameSize and whether
the string is ASCII into the split function itself.

Lastly, remove logic to set the MAGIC since that's already done on
L200. Thus, setting the magic is redundant.

There is no overall logic change.

Updates #12638

Change-Id: I26b6992578199abad723c2a2af7f4fc078af9c17
Reviewed-on: https://go-review.googlesource.com/14723Reviewed-by: David Symonds <dsymonds@golang.org>
Run-TryBot: David Symonds <dsymonds@golang.org>

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

The prose discussing composite literals referred to the composite
literal type with 'LiteralType', denoting the literal type's EBNF
production explicitly. Changed 'LiteralType' to 'literal type' to
remove the literal (no pun intended) connection and instead mean
the underlying type. Seems a simpler and more readable change
than referring to the underlying type everywhere explicitly.

Fixes #12717.

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

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

The usage message says:

	test [-c] [-i] [build and test flags] [packages] [flags for test binary]

but this was not what was implemented. Instead, after packages are named,
flag processing continues, which makes it impossible, for example, to pass
to the binary a flag with the same name as a test flag. This was triggered
by the -v flag in glog.

Consider this test:

package pkg

... imports ...

var v = flag.Int("v", 0, "v flag")

func TestFoo(t *testing.T) {
	if *v != 7 { log.Fatal(*v) }
}

Attempting to run this test with go test pkg -v=7 would give a usage
message. This change allows it. In fact it allows

	go test -v pkg -v=7

The solution is to implement the usage message. One compatibility
issue is that flags after the package name are no longer processed
as test flags, so this no longer works:

	go test foo -cover

One must write

	go test -cover foo

I do not think this is onerous but it must be called out in the
release notes.

Fixes #12177.

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

Change-Id: If886f15468680f7e1c589873066b4391eb9784b5
Reviewed-on: https://go-review.googlesource.com/14856Reviewed-by: Alan Donovan <adonovan@google.com>

Current result of DecimalConversion benchmark (for future reference):

BenchmarkDecimalConversion-8	   10000	    204770 ns/op

Measured on Mac Mini (late 2012) running OS X 10.10.5,
2.3 GHz Intel Core i7, 8 GB 1333 MHz DDR3.

Also: Removed comment suggesting to implement decimal by representing
digits as numbers 0..9 rather than ASCII chars '0'..'9' to avoid
repeated +/-'0' operations. Tried and it appears (per above benchmark)
that the +/-'0' operations are neglibile but the addition conversion
passes around it are not and that it makes things significantly slower.

Change-Id: I6ee033b1172043248093cc5d02abff5fc54c2e7a
Reviewed-on: https://go-review.googlesource.com/14857Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Alan Donovan <adonovan@google.com>

The actual behavior varies across platforms, and due to the inherent
race, we can't do anything better (other than to always return 0).

Fixes #12710.

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

Fixes #12709.

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

Enabled all but a handful of disabled Float formatting test cases.

Fixes #10991.

Change-Id: Id18e160e857be2743429a377000e996978015a1a
Reviewed-on: https://go-review.googlesource.com/14850Reviewed-by: Alan Donovan <adonovan@google.com>

Change-Id: I5183f767dadb6d24a34d2460d02e97ddbaab129a
Reviewed-on: https://go-review.googlesource.com/12546
Run-TryBot: Minux Ma <minux@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Reader fails to detect truncated streams since calls to io.ReadFull
do not check if the error is io.EOF.

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

Reader failed to detect truncated streams since calls to
io.ReadFull did not check if the error is io.EOF.

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

Otherwise IsNotExist does not account for not existent servers and shares.

Fixes #12374

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

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

The existing comment for regex.Split contains a plain text example,
while many of the other regex functions have runnable examples. This
change provides a runnable example for Split.

Change-Id: I5373f57f532fe843d7d0adcf4b513061ec797047
Reviewed-on: https://go-review.googlesource.com/14737Reviewed-by: Andrew Gerrand <adg@golang.org>
Run-TryBot: Andrew Gerrand <adg@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Fixes #12431

Change-Id: I67c42bf2cd9285f471387248fd9c22a16b158349
Reviewed-on: https://go-review.googlesource.com/14150Reviewed-by: Dmitri Shuralyov <shurcool@gmail.com>
Reviewed-by: Rob Pike <r@golang.org>

See discussion in https://go-review.googlesource.com/14830 .

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

Change-Id: I00e1eebbf5e1a01c8fad5ca5324aa8eec1e4d731
Reviewed-on: https://go-review.googlesource.com/14792Reviewed-by: Rick Hudson <rlh@golang.org>

Use movups to copy 16 bytes at a time.
Results (haswell):

name            old time/op  new time/op  delta
CopyFat8-48     0.62ns ± 3%  0.63ns ± 3%     ~     (p=0.535 n=20+20)
CopyFat12-48    0.92ns ± 2%  0.93ns ± 3%     ~     (p=0.594 n=17+18)
CopyFat16-48    1.23ns ± 2%  1.23ns ± 2%     ~     (p=0.839 n=20+19)
CopyFat24-48    1.85ns ± 2%  1.84ns ± 0%   -0.48%  (p=0.014 n=19+20)
CopyFat32-48    2.45ns ± 0%  2.45ns ± 1%     ~     (p=1.000 n=16+16)
CopyFat64-48    3.30ns ± 2%  2.14ns ± 1%  -35.00%  (p=0.000 n=20+18)
CopyFat128-48   6.05ns ± 0%  3.98ns ± 0%  -34.22%  (p=0.000 n=18+17)
CopyFat256-48   11.9ns ± 3%   7.7ns ± 0%  -35.87%  (p=0.000 n=20+17)
CopyFat512-48   23.0ns ± 2%  15.1ns ± 2%  -34.52%  (p=0.000 n=20+18)
CopyFat1024-48  44.8ns ± 1%  29.8ns ± 2%  -33.48%  (p=0.000 n=17+19)

Change-Id: I8a78773c656d400726a020894461e00c59f896bf
Reviewed-on: https://go-review.googlesource.com/14836
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>

Change-Id: I2e74e39628285e2fecaab712be6cff230619a6c2
Reviewed-on: https://go-review.googlesource.com/14778Reviewed-by: Alan Donovan <adonovan@google.com>

Instead of computing the final adjustment factor as a power of 10,
it's more efficient to split 10**e into 2**e * 5**e . Powers of 2
are trivially added to the Float exponent, and powers of 5 are
smaller and thus faster to compute.

Also, use a table of uint64 values rather than float64 values for
initial power value. uint64 values appear to be faster to convert
to Floats (useful for small exponents).

Added two small benchmarks to confirm that there's no regresssion.

benchmark                         old ns/op     new ns/op     delta
BenchmarkParseFloatSmallExp-8     17543         16220         -7.54%
BenchmarkParseFloatLargeExp-8     60865         59996         -1.43%

Change-Id: I3efd7556b023316f86f334137a67fe0c6d52f8ef
Reviewed-on: https://go-review.googlesource.com/14782Reviewed-by: Alan Donovan <adonovan@google.com>

https://go-review.googlesource.com/#/c/13778/ fixed this issue in math/big.
Remove restriction in compiler.

Fixes #11326.

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

This change addresses an integer underflow appearing only on systems
using a 32-bit int type. The patch addresses the problem by limiting the
length of unknown chunks to 0x7fffffff. This value appears to already be
checked for when parsing other chunk types, so the bug shouldn't appear
elsewhere in the package. The PNG spec recommends the maximum size for
any chunk to remain under 2^31, so this shouldn't cause errors with
valid images.

Fixes #12687

Change-Id: I17f0e1683515532c661cf2b0b2bc65309d1b7bb7
Reviewed-on: https://go-review.googlesource.com/14766Reviewed-by: Nigel Tao <nigeltao@golang.org>

A panic was in place for an impossible condition that turned
out to be possible if one used a macro to define a macro.

Another go-fuzz "win".

Fixes #12654.

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

Generate slices of method *Sig(nature)s instead of linked lists.
Remove custom lsort function in favor of sort.Interface.

Eliminates another use of stringsCompare.

Passes go build -a -toolexec 'toolstash -cmp' std cmd.

Change-Id: I9ed1664b7f55be9e967dd7196e396a76f6ea3422
Reviewed-on: https://go-review.googlesource.com/14559Reviewed-by: Dave Cheney <dave@cheney.net>

Recent changes caused vet to build the binary for each Test function.
This is wasteful and will become only more so as more tests are added.
Use testing.Main to build only once.

Verified that compilation errors still appear if the binary cannot be
built.

Before:
	real	0m11.169s
	user	0m18.328s
	sys	0m2.152s

After:
	real	0m5.132s
	user	0m9.404s
	sys	0m1.168s

Of course if the compiler were fast we might not notice, but vet is
a big program and growing bigger all the time, as are the tests.

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

Change-Id: I97ba31e758d3396842ad99a08af696e49a5f1a7d
Reviewed-on: https://go-review.googlesource.com/13954
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>

This means bringing over the examples flag and sorting doc.go.

Subsequent changes will generalize the examples flag to a general
test naming flag, but let's start with the original code.

No more changes to golang.org/x/tools please. This should not have
happened (and letting it happen was partly my fault).

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

The code assumed that if the first entry was unexported, all the
entries were. The fix is simple: delete a bunch of code.

Fixes #12286.

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

The fields step and redoState of struct scanner are now defined as
`func(s *scanner, c byte) int` instead of
`func(s *scanner, c int) int`, since bytes are sufficient.
Further changes improve the consistency in the scanner.go file.

Change-Id: Ifb85f2130d728d2b936d79914d87a1f0b5c6ee7d
Reviewed-on: https://go-review.googlesource.com/14801Reviewed-by: Andrew Gerrand <adg@golang.org>
Run-TryBot: Andrew Gerrand <adg@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Passes go build -a -toolexec 'toolstash -cmp' std cmd.

Change-Id: I2a87d31da74affdf3d0f358d0efdb3f1c646d917
Reviewed-on: https://go-review.googlesource.com/14759Reviewed-by: Dave Cheney <dave@cheney.net>

I was being too clever, as usual. Write the obvious code to make sure
that when we grow the buffer we don't overflow.

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

In the present code, there is no way for ok to ever return false, but
it still a good idea to check it.

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

Sometimes this read is instrumented by compiler when it creates
a temp to take address, but sometimes it is not (e.g. for global vars
compiler takes address of the global directly).

Instrument convT2E/I similarly to chansend and mapaccess.

Fixes #12664

Change-Id: Ia7807f15d735483996426c5f3aed60a33b279579
Reviewed-on: https://go-review.googlesource.com/14752Reviewed-by: Keith Randall <khr@golang.org>
Run-TryBot: Dmitry Vyukov <dvyukov@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Temporary fix to get the arm5 builder happy again.

Without hardware floating point, this test takes over 20 minutes to
run.

A proper solution would probably be to run all the benchmark tests,
but with a much lower iteration count, just to exercise the code.

Updates golang/go#12688

Change-Id: Ie56c93d3bf2a5a693a33217ba1b1df3c6c856442
Reviewed-on: https://go-review.googlesource.com/14775Reviewed-by: Dave Cheney <dave@cheney.net>
Reviewed-by: Minux Ma <minux@golang.org>

intLiteral is used by the gins wrappers in arm64, ppc64 and
mips64. Refactor the function to a method on gc.Node and update
the callers to use the common copy.

Change-Id: I2db90d801a9cb18f8526eb921e13daa75ca1cf6f
Reviewed-on: https://go-review.googlesource.com/14744Reviewed-by: Aram Hăvărneanu <aram@mgk.ro>
Reviewed-by: Dave Cheney <dave@cheney.net>
Run-TryBot: Dave Cheney <dave@cheney.net>
TryBot-Result: Gobot Gobot <gobot@golang.org>

This test fails on arm64 and some amd64 OSs and fails on Linux/amd64
if you remove the first runtime.GC(), which should be unnecessary, and
run it in all.bash (but not if you run it in isolation). I don't
understand any of these failures, so for now just remove this test.

TBR=rlh

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

Currently when the GC prints an object for debugging (e.g., for a
failed invalidptr or checkmark check), it dumps the entire object. To
avoid inundating the user with output for really large objects, limit
this to printing just the first 128 words (which are most likely to be
useful in identifying the type of an object) and the 32 words around
the problematic field.

Change-Id: Id94a5c9d8162f8bd9b2a63bf0b1bfb0adde83c68
Reviewed-on: https://go-review.googlesource.com/14764Reviewed-by: Rick Hudson <rlh@golang.org>

By default, the runtime panics if it detects a pointer to an
unallocated span. At this point, this usually catches bad uses of
unsafe or cgo in user code (though it could also catch runtime bugs).
Unfortunately, the rather cryptic error misleads users, offers users
little help with debugging their own problem, and offers the Go
developers little help with root-causing.

Improve the error message in various ways. First, the wording is
improved to make it clearer what condition was detected and to suggest
that this may be the result of incorrect use of unsafe or cgo. Second,
we add a dump of the object containing the bad pointer so that there's
at least some hope of figuring out why a bad pointer was stored in the
Go heap.

Change-Id: I57b91b12bc3cb04476399d7706679e096ce594b9
Reviewed-on: https://go-review.googlesource.com/14763Reviewed-by: Rick Hudson <rlh@golang.org>