Fixes #16884
Updates #16360

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

Modifies context package to use map[]struct{} rather than map[]bool,
since the map is intended as a set object.  Also adds Benchmarks to
the context package switching between different types of root nodes
and a tree with different depths.

Included below are bytes deltas between the old and new code, using
these benchmarks.

benchmark                                                       old bytes     new bytes     delta
BenchmarkContextCancelTree/depth=1/Root=Background-8            176           176           +0.00%
BenchmarkContextCancelTree/depth=1/Root=OpenCanceler-8          560           544           -2.86%
BenchmarkContextCancelTree/depth=1/Root=ClosedCanceler-8        352           352           +0.00%
BenchmarkContextCancelTree/depth=10/Root=Background-8           3632          3488          -3.96%
BenchmarkContextCancelTree/depth=10/Root=OpenCanceler-8         4016          3856          -3.98%
BenchmarkContextCancelTree/depth=10/Root=ClosedCanceler-8       1936          1936          +0.00%
BenchmarkContextCancelTree/depth=100/Root=Background-8          38192         36608         -4.15%
BenchmarkContextCancelTree/depth=100/Root=OpenCanceler-8        38576         36976         -4.15%
BenchmarkContextCancelTree/depth=100/Root=ClosedCanceler-8      17776         17776         +0.00%
BenchmarkContextCancelTree/depth=1000/Root=Background-8         383792        367808        -4.16%
BenchmarkContextCancelTree/depth=1000/Root=OpenCanceler-8       384176        368176        -4.16%
BenchmarkContextCancelTree/depth=1000/Root=ClosedCanceler-8     176176        176176        +0.00%

Change-Id: I699ad704d9f7b461214e1651d24941927315b525
Reviewed-on: https://go-review.googlesource.com/25270Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>

Currently the footnote says "gcc is required only if you plan to use cgo",
but the footnote was referenced from the text:

   "use the clang or gcc† that comes with Xcode‡ for cgo support"

That seems to imply that clang doesn't get you cgo support on OS X,
which isn't true. The update text matches what the install-source.html
page says.

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

Benchmarks are much better for opaque fills and slightly worse on non
opaque fills. I think that on balance, this is still a win.

When the source is uniform(color.RGBA{0x11, 0x22, 0x33, 0xff}):
name        old time/op  new time/op  delta
FillOver-8   966µs ± 1%    32µs ± 1%  -96.67%  (p=0.000 n=10+10)
FillSrc-8   32.4µs ± 1%  32.2µs ± 1%     ~      (p=0.053 n=9+10)

When the source is uniform(color.RGBA{0x11, 0x22, 0x33, 0x44}):
name        old time/op  new time/op  delta
FillOver-8   962µs ± 0%  1018µs ± 0%  +5.85%   (p=0.000 n=9+10)
FillSrc-8   32.2µs ± 1%  32.1µs ± 0%    ~     (p=0.148 n=10+10)

Change-Id: I52ec6d5fcd0fbc6710cef0e973a21ee7827c0dd9
Reviewed-on: https://go-review.googlesource.com/28790Reviewed-by: David Crawshaw <crawshaw@golang.org>

First step towards cleaning up format use. Not yet enabled.

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

STFLE does not necessarily write to all the double-words that are
requested. It is therefore necessary to clear the target memory
before calling STFLE in order to ensure that the facility list does
not contain false positives.

Fixes #17032.

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

Use MOVW, instead of MOVV, to pass an int32 arg. Also no need to
restore arg registers.

Fix big-endian MIPS64 build.

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

It is better to document what golang does, rather than how it differs
from languages which readers may or may not know.

That the output format is based on the type is basically self-evident
if you consider this just in go terms.

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

Currently, path resolution is done using the un-escaped version of
paths. This means that path elements like one%2ftwo%2fthree are
handled incorrectly, and optional encodings (%2d vs. -) are dropped.

This function makes escaped handling consistent with Parse: provided
escapings are honoured, and RawPath is only set if necessary.

A helper method setPath is introduced to handle the correct setting of
Path and RawPath given the encoded path.

Fixes #16947

Change-Id: I40b1215e9066e88ec868b41635066eee220fde37
Reviewed-on: https://go-review.googlesource.com/28343
Run-TryBot: Dave Day <djd@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Introduced by https://go-review.googlesource.com/#/c/28331/ .

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

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

Change-Id: Ie73fb460a3838c6d1b9348965a8b69c1bfa6a882
Reviewed-on: https://go-review.googlesource.com/28341Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Dave Cheney <dave@cheney.net>

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

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

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

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

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

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

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

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

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

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

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

So we can submit a sequence of older changes that don't yet
update the formats in this file. We will then re-enable the
test with the updated formats.

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

Fixes #11254.
Updates #16360.

Implements examples using all exported functions.

This CL also updates Decode documentation to
state that only hexadecimal characters are accepted
in the source slice src, but also that the length
of src must be even.

Change-Id: Id016a4ba814f940cd300f26581fb4b9d2aded306
Reviewed-on: https://go-review.googlesource.com/28482Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>

Change-Id: Ia5bf72b70e6f6522d6fb8cd050e78f862d37b5ae
Reviewed-on: https://go-review.googlesource.com/27936
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>

Hop-by-hop headers (explicitly mentioned in RFC 2616) were already
removed from the response. This removes the custom hop-by-hop
headers listed in the "Connection" header of the response.

Updates #16875

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

The previous check for characters inside of a JSON string that needed
to be escaped performed seven different boolean comparisons before
determining that a ASCII character did not need to be escaped. Most
characters do not need to be escaped, so this check can be done in a
more performant way.

Use the same strategy as the unicode package for precomputing a range
of characters that need to be escaped, then do a single lookup into a
character array to determine whether the character needs escaping.

On an AWS c4.large node:

$ benchstat benchmarks/master-bench benchmarks/json-table-bench
name                   old time/op    new time/op     delta
CodeEncoder-2            19.0ms ± 0%     15.5ms ± 1%  -18.16%        (p=0.000 n=19+20)
CodeMarshal-2            20.1ms ± 1%     16.8ms ± 2%  -16.35%        (p=0.000 n=20+21)
CodeDecoder-2            49.3ms ± 1%     49.5ms ± 2%     ~           (p=0.498 n=16+20)
DecoderStream-2           416ns ± 0%      416ns ± 1%     ~           (p=0.978 n=19+19)
CodeUnmarshal-2          51.0ms ± 1%     50.9ms ± 1%     ~           (p=0.490 n=19+17)
CodeUnmarshalReuse-2     48.5ms ± 2%     48.5ms ± 2%     ~           (p=0.989 n=20+19)
UnmarshalString-2         541ns ± 1%      532ns ± 1%   -1.75%        (p=0.000 n=20+21)
UnmarshalFloat64-2        485ns ± 1%      481ns ± 1%   -0.92%        (p=0.000 n=20+21)
UnmarshalInt64-2          429ns ± 1%      427ns ± 1%   -0.49%        (p=0.000 n=19+20)
Issue10335-2              631ns ± 1%      619ns ± 1%   -1.84%        (p=0.000 n=20+20)
NumberIsValid-2          19.1ns ± 0%     19.1ns ± 0%     ~     (all samples are equal)
NumberIsValidRegexp-2     689ns ± 1%      690ns ± 0%     ~           (p=0.150 n=20+20)
SkipValue-2              14.0ms ± 0%     14.0ms ± 0%   -0.05%        (p=0.000 n=18+18)
EncoderEncode-2           525ns ± 2%      512ns ± 1%   -2.33%        (p=0.000 n=20+18)

name                   old speed      new speed       delta
CodeEncoder-2           102MB/s ± 0%    125MB/s ± 1%  +22.20%        (p=0.000 n=19+20)
CodeMarshal-2          96.6MB/s ± 1%  115.6MB/s ± 2%  +19.56%        (p=0.000 n=20+21)
CodeDecoder-2          39.3MB/s ± 1%   39.2MB/s ± 2%     ~           (p=0.464 n=16+20)
CodeUnmarshal-2        38.1MB/s ± 1%   38.1MB/s ± 1%     ~           (p=0.525 n=19+17)
SkipValue-2             143MB/s ± 0%    143MB/s ± 0%   +0.05%        (p=0.000 n=18+18)

I also took the data set reported in #5683 (browser
telemetry data from Mozilla), added named structs for
the data set, and turned it into a proper benchmark:
https://github.com/kevinburke/jsonbench/blob/master/go/bench_test.go

The results from that test are similarly encouraging. On a 64-bit
Mac:

$ benchstat benchmarks/master-benchmark benchmarks/json-table-benchmark
name              old time/op    new time/op    delta
CodeMarshal-4       1.19ms ± 2%    1.08ms ± 2%   -9.33%  (p=0.000 n=21+17)
Unmarshal-4         3.09ms ± 3%    3.06ms ± 1%   -0.83%  (p=0.027 n=22+17)
UnmarshalReuse-4    3.04ms ± 1%    3.04ms ± 1%     ~     (p=0.169 n=20+15)

name              old speed      new speed      delta
CodeMarshal-4     80.3MB/s ± 1%  88.5MB/s ± 1%  +10.29%  (p=0.000 n=21+17)
Unmarshal-4       31.0MB/s ± 2%  31.2MB/s ± 1%   +0.83%  (p=0.025 n=22+17)

On the c4.large:

$ benchstat benchmarks/master-bench benchmarks/json-table-bench
name              old time/op    new time/op    delta
CodeMarshal-2       1.10ms ± 1%    0.98ms ± 1%  -10.12%  (p=0.000 n=20+54)
Unmarshal-2         2.82ms ± 1%    2.79ms ± 0%   -1.09%  (p=0.000 n=20+51)
UnmarshalReuse-2    2.80ms ± 0%    2.77ms ± 0%   -1.03%  (p=0.000 n=20+52)

name              old speed      new speed      delta
CodeMarshal-2     87.3MB/s ± 1%  97.1MB/s ± 1%  +11.27%  (p=0.000 n=20+54)
Unmarshal-2       33.9MB/s ± 1%  34.2MB/s ± 0%   +1.10%  (p=0.000 n=20+51)

For what it's worth, I tried other heuristics - short circuiting the
conditional for common ASCII characters, for example:

if (b >= 63 && b != 92) || (b >= 39 && b <= 59) || (rest of the conditional)

This offered a speedup around 7-9%, not as large as the submitted
change.

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

Remove the runeBytes buffer and write the utf8 encoding directly
to the internal buf byte slice.

name         old time/op   new time/op   delta
WriteRune-4   80.5µs ± 2%   57.1µs ± 2%  -29.06%  (p=0.000 n=20+20)

name         old speed     new speed     delta
WriteRune-4  153MB/s ± 2%  215MB/s ± 2%  +40.96%  (p=0.000 n=20+20)

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

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

When arg length is wrong, op is not set, so it always prints
"should have 0 args".

Change-Id: If7bcb41d993919d0038d2a09e16188c79dfbd858
Reviewed-on: https://go-review.googlesource.com/28831Reviewed-by: Keith Randall <khr@golang.org>

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

Before this CL the runtime prevented printing of overlong strings with the print
function when the length of the string was determined to be corrupted.
Corruption was checked by comparing the string size against the limit
which was stored in maxstring.

However maxstring was not updated everywhere were go strings were created
e.g. for string constants during compile time. Thereby the check for maximum
string length prevented the printing of some valid strings.

The protection maxstring provided did not warrant the bookkeeping
and global synchronization needed to keep maxstring updated to the
correct limit everywhere.

Fixes #16999

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

Fixes #14196

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

Since FuncTypes are represented as structs rather than linking the
parameter lists together, we no longer need to worry about duplicating
the parameter lists.

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

We were already making a copy of the map before removing
hop-by-hop headers. This commit does the same for proxied
headers mentioned in the "Connection" header.

A test is added to ensure request headers are not modified.

Updates #16875

Change-Id: I85329d212787958d5ad818915eb0538580a4653a
Reviewed-on: https://go-review.googlesource.com/28493Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>

Updates #16360

Change-Id: I5927cffa961cd85539a3ba9606b116c5996d1096
Reviewed-on: https://go-review.googlesource.com/26696Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>

Updates #16983
Updates #16996

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

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

https://golang.org/cl/27206 fixed the dtoi function such that
it now properly parses negative number. Ironically, this causes
several other functions that depended on dtoi to now (incorrectly)
parse negative numbers.

For example, ParseCIDR("-1.0.0.0/32") used to be rejected prior to the
above CL, but is now accepted even though it is an invalid CIDR notation.
This CL fixes that regression.

We fix this by removing the signed parsing logic entirely from dtoi.
It was introduced relatively recently in https://golang.org/cl/12447
to fix a bug where an invalid port was improperly being parsed as OK.
It seems to me that the fix in that CL to the port handling logic was
sufficient such that a change to dtoi was unnecessary.

Updates #16350

Change-Id: I414bb1aa27d0a226ebd4b05a09cb40d784691b43
Reviewed-on: https://go-review.googlesource.com/28414Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Mikio Hara <mikioh.mikioh@gmail.com>
Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com>