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>

TestFormats finds potential (Printf, etc.) format strings.
If they are used in a call, the format verbs are verified
based on the matching argument type against a precomputed
table of valid formats (formatMapping, below). The table
can be used to automatically rewrite format strings with
the -u flag.

Run as: go test -run Formats [-u]

A formatMapping based on the existing formats is printed
when the test is run in verbose mode (-v flag). The table
needs to be updated whenever a new (type, format) combination
is found and the format verb is not 'v' (as in "%v").

Known bugs:
- indexed format strings ("%[2]s", etc.) are not suported
  (the test will fail)
- format strings that are not simple string literals cannot
  be updated automatically
  (the test will fail with respective warnings)

Change-Id: I1ca5bb6421d57ac78a00f1a80b9547a72837adc9
Reviewed-on: https://go-review.googlesource.com/28419
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>

IndexHard4-4      1.50ms ± 2%  0.71ms ± 0%  -52.36%  (p=0.000 n=20+19)

This also fixes a bug, that caused a string of length 16 to use
two 8-byte comparisons instead of one 16-byte. And adds a test for
cases when partial_match fails.

Change-Id: I1ee8fc4e068bb36c95c45de78f067c822c0d9df0
Reviewed-on: https://go-review.googlesource.com/22551
Run-TryBot: Ilya Tocar <ilya.tocar@intel.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>

Redo of CL 28575 with fixed test.
We're in a pre-KeepAlive world for a bit yet, the old tests
were in a client which was in a post-KeepAlive world.

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

This is was already done for Unix in https://golang.org/cl/6701 +
https://golang.org/cl/8192. Do it for Windows also.

Fixes #16988

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

This has always been the case but it was not obvious from the documentation.
The reason for the quoting is that String() may return an abbreviated string,
starting with double-quote (") but ending in ... (w/o a quote). The missing
quote indicates the abbreviation (in contrast to a string ending in ...").

constant.StringVal can be used to obtain the unquoted string of a String Value.

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

Reason for revert: broke the build due to cherrypick;
relies on an unsubmitted parent CL.

Original issue's description:
> cmd/compile: ignore contentEscapes for marking nodes as escaping
> 
> We can still stack allocate and VarKill nodes which don't
> escape but their content does.
> 
> Fixes #16996
> 
> Change-Id: If8aa0fcf2c327b4cb880a3d5af8d213289e6f6bf
> Reviewed-on: https://go-review.googlesource.com/28575
> Run-TryBot: Keith Randall <khr@golang.org>
> TryBot-Result: Gobot Gobot <gobot@golang.org>
> Reviewed-by: David Chase <drchase@google.com>
> 

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

We can still stack allocate and VarKill nodes which don't
escape but their content does.

Fixes #16996

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