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

Like int/rat/float conversions, move this functionality into separate
implementation and test files.

No implementation changes besides the move.

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

- renamed (nat) itoa to utoa (since that's what it is)
- added (nat) itoa that takes a sign parameter; this helps removing a few string copies
- used buffers instead of string+ in Rat conversions

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

This makes the Int conversion routines match the respective strconv
and big.Float conversion routines.

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

When link-layer information is wrapped with sockaddr_dl, we need to
follow the len field of sockaddr_dl. When link-layer information is
naked, we need to use the length of whole link-layer information.

Fixes #12641.

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

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

The Scan function's interface to the split function was not sufficient
to handle an empty final token in a pure function; state was required.
This was ugly.

We introduce a special error value that a split function can return
that signals that this token is OK, but is the last one and scanning
should stop immediately _after_ this token.

The same effect could be achieved using the same trick (a special
error value) and checking for that error after Scan finishes, but it's
a little clumsy. Providing a published sentinel value in bufio is
cleaner and means everyone can use the same trick. The result
is an error-free scan.

Rewrite the test (that was only barely working) to use the value
and be more robust.

Also write a new example showing how to do it.

Fixes #11836

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

Some linker flags should only be applied when performing the final
linking step for a shared library or executable, etc. In other
contexts, they're either invalid, or meaningless to apply (so should
not be specified).

When an external linker is used (either directly by Go or by the
compiler driver used by cgo), -rpath and -rpath-link should only be
specified in the final linking step.  On platforms such as Solaris,
ld(1) will reject its use in any other scenario (such as when linking
relocatable objects).

This change is necessary because Go does not currently offer a way to
specify LDFLAGS based on when they should be applied.

Fixes #12115

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

Eliminated unnecessary string conversions throughout and removed
(internal) capability for arbitrary character sets in conversion
routines (functionality was not exported and not used internally).

benchmark                         old ns/op     new ns/op     delta
BenchmarkDecimalConversion-8      198283        187085        -5.65%
BenchmarkStringPiParallel-8       46116         47822         +3.70%
BenchmarkString10Base2-8          216           166           -23.15%
BenchmarkString100Base2-8         886           762           -14.00%
BenchmarkString1000Base2-8        7296          6625          -9.20%
BenchmarkString10000Base2-8       72371         65563         -9.41%
BenchmarkString100000Base2-8      725849        672766        -7.31%
BenchmarkString10Base8-8          160           114           -28.75%
BenchmarkString100Base8-8         398           309           -22.36%
BenchmarkString1000Base8-8        2650          2244          -15.32%
BenchmarkString10000Base8-8       24974         21745         -12.93%
BenchmarkString100000Base8-8      245457        217489        -11.39%
BenchmarkString10Base10-8         337           288           -14.54%
BenchmarkString100Base10-8        1298          1046          -19.41%
BenchmarkString1000Base10-8       6200          5752          -7.23%
BenchmarkString10000Base10-8      24942         22589         -9.43%
BenchmarkString100000Base10-8     8012921       7947152       -0.82%
BenchmarkString10Base16-8         156           107           -31.41%
BenchmarkString100Base16-8        344           255           -25.87%
BenchmarkString1000Base16-8       2067          1705          -17.51%
BenchmarkString10000Base16-8      19026         16112         -15.32%
BenchmarkString100000Base16-8     184038        163457        -11.18%

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

The test case is
	go doc rand.Float64
The first package it finds is crypto/rand, which does not have a Float64.
Before this change, cmd/doc would stop there even though math/rand
has the symbol. After this change, we get:

	% go doc rand.Float64
	package rand // import "math/rand"

	func Float64() float64

	    Float64 returns, as a float64, a pseudo-random number in [0.0,1.0) from the
	    default Source.
	%

Another nice consequence is that if a symbol is not found, we might get
a longer list of packages that were examined:

	% go doc rand.Int64
	doc: no symbol Int64 in packages crypto/rand, math/rand
	exit status 1
	%

This change introduces a coroutine to scan the file system so that if
the symbol is not found, the coroutine can deliver another path to try.
(This is darned close to the original motivation for coroutines.)
Paths are delivered on an unbuffered channel so the scanner does
not proceed until candidate paths are needed.

The scanner is attached to a new type, called Dirs, that caches the results
so if we need to scan a second time, we don't walk the file system
again. This is significantly more efficient than the existing code, which
could scan the tree multiple times looking for a package with
the symbol.

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

Also: removed unnecessary BUG comment (was fixed).

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

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

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

Only one use of stringsCompare is left. Cannot simply be replaced by
strings.Compare for bootstrapping reasons I guess.
Moving the function away from util.go to the actual destination data.go
also would not help much. So I left this one unchanged for readability and convenience.

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

Moves the functions:
        isSpace(int) bool
        isAlpha(int) bool
        isDigit(int) bool
        isAlnum(int) bool
        plan9quote(string) string

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

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

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

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

When parsing the multipart data, if the delimiter appears but doesn't
finish with -- or \n or \r\n, it assumes the data can be consumed. This
is incorrect when the peeking buffer finishes with --delimiter-

Fixes #12662

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

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>