summaryrefslogtreecommitdiff
path: root/src/encoding/json
Commit message (Collapse)AuthorAgeFilesLines
* encoding/json: ignore embedded fields of pointers to unexported non-structsJoe Tsai2017-07-222-70/+182
| | | | | | | | | | | | | | | | | | | | | | https://golang.org/cl/33773 fixes the JSON marshaler to avoid serializing embedded fields on unexported types of non-struct types. However, Go allows embedding pointer to types, so the check for whether the field is a non-struct type must first dereference the pointer to get at the underlying type. Furthermore, due to a edge-case in the behavior of StructField.PkgPath not being a reliable indicator of whether the field is unexported (see #21122), we use our own logic to determine whether the field is exported or not. The logic in this CL may be simplified depending on what happens in #21122. Fixes #21121 Updates #21122 Change-Id: I8dfd1cdfac8a87950df294a566fb96dfd04fd749 Reviewed-on: https://go-review.googlesource.com/50711 Reviewed-by: Ian Lance Taylor <iant@golang.org> Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
* encoding/json: fix indentation in Decode stream exampleIccha Sethi2017-07-151-8/+8
| | | | | | | | | | | | | | The existing example for Decoder.Decode (Stream) had excessive indentation in the godoc interface for the const jsonStream, making it hard to read. This fixes the indentation in the example_test.go to improve the readability in godoc. Helps #21026. Change-Id: I16f56b82182da1dcc73cca44e535a7f5695e975d Reviewed-on: https://go-review.googlesource.com/48910 Reviewed-by: Dmitri Shuralyov <shurcool@gmail.com> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
* Revert "encoding/json: reduce unmarshal mallocs for unmapped fields"Brad Fitzpatrick2017-06-291-28/+34
| | | | | | | | | | | | | | | | This reverts commit df68afd07ce67727 (https://golang.org/cl/33276) Reason for revert: made other benchmarks worse Fixes #20693 (details) Updates #17914 Updates #10335 Change-Id: If451b620803ccb0536b89c76c4353d2185d57d7e Reviewed-on: https://go-review.googlesource.com/47211 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Russ Cox <rsc@golang.org>
* encoding/json: don't marshal unexported embedded fields of non struct typethoeni2017-06-142-1/+54
| | | | | | | | | | | | | | | | | | | | | | | | | | | Marshal must process unexported embedded fields of struct type, looking for exported fields in those structs. However, it must not process unexported embedded fields of non-struct type. For example, consider: type t1 struct { X int } type t2 int type T struct { t1 t2 } When considering T, Marshal must process t1 to find t1.X. Marshal must not process t2, but it was. Fix that. Fixes #18009 Change-Id: I62ba0b65ba30fd927990e101a26405a9998787a3 Reviewed-on: https://go-review.googlesource.com/33773 Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by: Russ Cox <rsc@golang.org>
* encoding/json: clarify unmarshaling behaviour on bad fieldsAlberto Donizetti2017-06-051-1/+3
| | | | | | | | Fixes #19526 Change-Id: Ifaaf454e0e89fdf4309118c2e2e6ac0d0a43c39d Reviewed-on: https://go-review.googlesource.com/44711 Reviewed-by: Ian Lance Taylor <iant@golang.org>
* encoding/json: replace encoderCache RWMutex with a sync.MapBryan C. Mills2017-04-281-21/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This provides a moderate speedup for encoding when using many CPU cores. name old time/op new time/op delta CodeEncoder 14.1ms ±10% 13.5ms ± 4% ~ (p=0.867 n=8+7) CodeEncoder-6 2.58ms ± 8% 2.72ms ± 6% ~ (p=0.065 n=8+8) CodeEncoder-48 629µs ± 1% 629µs ± 1% ~ (p=0.867 n=8+7) CodeMarshal 14.9ms ± 5% 14.9ms ± 5% ~ (p=0.721 n=8+8) CodeMarshal-6 3.28ms ±11% 3.24ms ±12% ~ (p=0.798 n=8+8) CodeMarshal-48 739µs ± 1% 745µs ± 2% ~ (p=0.328 n=8+8) CodeDecoder 49.7ms ± 4% 49.2ms ± 4% ~ (p=0.463 n=7+8) CodeDecoder-6 10.1ms ± 8% 10.4ms ± 3% ~ (p=0.232 n=7+8) CodeDecoder-48 2.60ms ± 3% 2.61ms ± 2% ~ (p=1.000 n=8+8) DecoderStream 352ns ± 5% 344ns ± 4% ~ (p=0.077 n=8+8) DecoderStream-6 485ns ± 8% 503ns ± 6% ~ (p=0.123 n=8+8) DecoderStream-48 522ns ± 7% 520ns ± 5% ~ (p=0.959 n=8+8) CodeUnmarshal 52.2ms ± 5% 54.4ms ±18% ~ (p=0.955 n=7+8) CodeUnmarshal-6 12.4ms ± 6% 12.3ms ± 6% ~ (p=0.878 n=8+8) CodeUnmarshal-48 3.46ms ± 7% 3.40ms ± 9% ~ (p=0.442 n=8+8) CodeUnmarshalReuse 48.9ms ± 6% 50.3ms ± 7% ~ (p=0.279 n=8+8) CodeUnmarshalReuse-6 10.3ms ±11% 10.3ms ±10% ~ (p=0.959 n=8+8) CodeUnmarshalReuse-48 2.68ms ± 3% 2.67ms ± 4% ~ (p=0.878 n=8+8) UnmarshalString 476ns ± 7% 474ns ± 7% ~ (p=0.644 n=8+8) UnmarshalString-6 164ns ± 9% 160ns ±10% ~ (p=0.556 n=8+8) UnmarshalString-48 181ns ± 0% 177ns ± 2% -2.36% (p=0.001 n=7+7) UnmarshalFloat64 414ns ± 4% 418ns ± 4% ~ (p=0.382 n=8+8) UnmarshalFloat64-6 147ns ± 9% 143ns ±16% ~ (p=0.457 n=8+8) UnmarshalFloat64-48 176ns ± 2% 174ns ± 2% ~ (p=0.118 n=8+8) UnmarshalInt64 369ns ± 4% 354ns ± 1% -3.85% (p=0.005 n=8+7) UnmarshalInt64-6 132ns ±11% 132ns ±10% ~ (p=0.982 n=8+8) UnmarshalInt64-48 177ns ± 3% 174ns ± 2% -1.84% (p=0.028 n=8+7) Issue10335 540ns ± 5% 535ns ± 0% ~ (p=0.330 n=7+7) Issue10335-6 159ns ± 8% 164ns ± 8% ~ (p=0.246 n=8+8) Issue10335-48 186ns ± 1% 182ns ± 2% -1.89% (p=0.010 n=8+8) Unmapped 1.74µs ± 2% 1.76µs ± 6% ~ (p=0.181 n=6+8) Unmapped-6 414ns ± 5% 402ns ±10% ~ (p=0.244 n=7+8) Unmapped-48 226ns ± 2% 224ns ± 2% ~ (p=0.144 n=7+8) NumberIsValid 20.1ns ± 4% 19.7ns ± 3% ~ (p=0.204 n=8+8) NumberIsValid-6 20.4ns ± 8% 22.2ns ±16% ~ (p=0.129 n=7+8) NumberIsValid-48 23.1ns ±12% 23.8ns ± 8% ~ (p=0.104 n=8+8) NumberIsValidRegexp 629ns ± 5% 622ns ± 0% ~ (p=0.148 n=7+7) NumberIsValidRegexp-6 757ns ± 2% 725ns ±14% ~ (p=0.351 n=8+7) NumberIsValidRegexp-48 757ns ± 2% 723ns ±13% ~ (p=0.521 n=8+8) SkipValue 13.2ms ± 9% 13.3ms ± 1% ~ (p=0.130 n=8+8) SkipValue-6 15.1ms ±10% 14.8ms ± 2% ~ (p=0.397 n=7+8) SkipValue-48 13.9ms ±12% 14.3ms ± 1% ~ (p=0.694 n=8+7) EncoderEncode 433ns ± 4% 410ns ± 3% -5.48% (p=0.001 n=8+8) EncoderEncode-6 221ns ±15% 75ns ± 5% -66.15% (p=0.000 n=7+8) EncoderEncode-48 161ns ± 4% 19ns ± 7% -88.29% (p=0.000 n=7+8) name old speed new speed delta CodeEncoder 139MB/s ±10% 144MB/s ± 4% ~ (p=0.844 n=8+7) CodeEncoder-6 756MB/s ± 8% 714MB/s ± 6% ~ (p=0.065 n=8+8) CodeEncoder-48 3.08GB/s ± 1% 3.09GB/s ± 1% ~ (p=0.867 n=8+7) CodeMarshal 130MB/s ± 5% 130MB/s ± 5% ~ (p=0.721 n=8+8) CodeMarshal-6 594MB/s ±10% 601MB/s ±11% ~ (p=0.798 n=8+8) CodeMarshal-48 2.62GB/s ± 1% 2.60GB/s ± 2% ~ (p=0.328 n=8+8) CodeDecoder 39.0MB/s ± 4% 39.5MB/s ± 4% ~ (p=0.463 n=7+8) CodeDecoder-6 189MB/s ±13% 187MB/s ± 3% ~ (p=0.505 n=8+8) CodeDecoder-48 746MB/s ± 2% 745MB/s ± 2% ~ (p=1.000 n=8+8) CodeUnmarshal 37.2MB/s ± 5% 35.9MB/s ±16% ~ (p=0.955 n=7+8) CodeUnmarshal-6 157MB/s ± 6% 158MB/s ± 6% ~ (p=0.878 n=8+8) CodeUnmarshal-48 561MB/s ± 7% 572MB/s ±10% ~ (p=0.442 n=8+8) SkipValue 141MB/s ±10% 139MB/s ± 1% ~ (p=0.130 n=8+8) SkipValue-6 131MB/s ± 3% 133MB/s ± 2% ~ (p=0.662 n=6+8) SkipValue-48 138MB/s ±11% 132MB/s ± 1% ~ (p=0.281 n=8+7) name old alloc/op new alloc/op delta CodeEncoder 45.9kB ± 0% 45.9kB ± 0% -0.02% (p=0.002 n=7+8) CodeEncoder-6 55.1kB ± 0% 55.1kB ± 0% -0.01% (p=0.002 n=7+8) CodeEncoder-48 110kB ± 0% 110kB ± 0% -0.00% (p=0.030 n=7+8) CodeMarshal 4.59MB ± 0% 4.59MB ± 0% -0.00% (p=0.000 n=8+8) CodeMarshal-6 4.59MB ± 0% 4.59MB ± 0% -0.00% (p=0.000 n=8+8) CodeMarshal-48 4.59MB ± 0% 4.59MB ± 0% -0.00% (p=0.001 n=7+8) CodeDecoder 2.28MB ± 5% 2.21MB ± 0% ~ (p=0.257 n=8+7) CodeDecoder-6 2.43MB ±11% 2.51MB ± 0% ~ (p=0.473 n=8+8) CodeDecoder-48 2.93MB ± 0% 2.93MB ± 0% ~ (p=0.554 n=7+8) DecoderStream 16.0B ± 0% 16.0B ± 0% ~ (all equal) DecoderStream-6 16.0B ± 0% 16.0B ± 0% ~ (all equal) DecoderStream-48 16.0B ± 0% 16.0B ± 0% ~ (all equal) CodeUnmarshal 3.28MB ± 0% 3.28MB ± 0% ~ (p=1.000 n=7+7) CodeUnmarshal-6 3.28MB ± 0% 3.28MB ± 0% ~ (p=0.593 n=8+8) CodeUnmarshal-48 3.28MB ± 0% 3.28MB ± 0% ~ (p=0.670 n=8+8) CodeUnmarshalReuse 1.87MB ± 0% 1.88MB ± 1% +0.48% (p=0.011 n=7+8) CodeUnmarshalReuse-6 1.90MB ± 1% 1.90MB ± 1% ~ (p=0.589 n=8+8) CodeUnmarshalReuse-48 1.96MB ± 0% 1.96MB ± 0% +0.00% (p=0.002 n=7+8) UnmarshalString 304B ± 0% 304B ± 0% ~ (all equal) UnmarshalString-6 304B ± 0% 304B ± 0% ~ (all equal) UnmarshalString-48 304B ± 0% 304B ± 0% ~ (all equal) UnmarshalFloat64 292B ± 0% 292B ± 0% ~ (all equal) UnmarshalFloat64-6 292B ± 0% 292B ± 0% ~ (all equal) UnmarshalFloat64-48 292B ± 0% 292B ± 0% ~ (all equal) UnmarshalInt64 289B ± 0% 289B ± 0% ~ (all equal) UnmarshalInt64-6 289B ± 0% 289B ± 0% ~ (all equal) UnmarshalInt64-48 289B ± 0% 289B ± 0% ~ (all equal) Issue10335 312B ± 0% 312B ± 0% ~ (all equal) Issue10335-6 312B ± 0% 312B ± 0% ~ (all equal) Issue10335-48 312B ± 0% 312B ± 0% ~ (all equal) Unmapped 344B ± 0% 344B ± 0% ~ (all equal) Unmapped-6 344B ± 0% 344B ± 0% ~ (all equal) Unmapped-48 344B ± 0% 344B ± 0% ~ (all equal) NumberIsValid 0.00B 0.00B ~ (all equal) NumberIsValid-6 0.00B 0.00B ~ (all equal) NumberIsValid-48 0.00B 0.00B ~ (all equal) NumberIsValidRegexp 0.00B 0.00B ~ (all equal) NumberIsValidRegexp-6 0.00B 0.00B ~ (all equal) NumberIsValidRegexp-48 0.00B 0.00B ~ (all equal) SkipValue 0.00B 0.00B ~ (all equal) SkipValue-6 0.00B 0.00B ~ (all equal) SkipValue-48 15.0B ±167% 0.0B ~ (p=0.200 n=8+8) EncoderEncode 8.00B ± 0% 0.00B -100.00% (p=0.000 n=8+8) EncoderEncode-6 8.00B ± 0% 0.00B -100.00% (p=0.000 n=8+8) EncoderEncode-48 8.00B ± 0% 0.00B -100.00% (p=0.000 n=8+8) name old allocs/op new allocs/op delta CodeEncoder 1.00 ± 0% 0.00 -100.00% (p=0.000 n=8+8) CodeEncoder-6 1.00 ± 0% 0.00 -100.00% (p=0.000 n=8+8) CodeEncoder-48 1.00 ± 0% 0.00 -100.00% (p=0.000 n=8+8) CodeMarshal 17.0 ± 0% 16.0 ± 0% -5.88% (p=0.000 n=8+8) CodeMarshal-6 17.0 ± 0% 16.0 ± 0% -5.88% (p=0.000 n=8+8) CodeMarshal-48 17.0 ± 0% 16.0 ± 0% -5.88% (p=0.000 n=8+8) CodeDecoder 89.6k ± 0% 89.5k ± 0% ~ (p=0.154 n=8+7) CodeDecoder-6 89.8k ± 0% 89.9k ± 0% ~ (p=0.467 n=8+8) CodeDecoder-48 90.5k ± 0% 90.5k ± 0% ~ (p=0.533 n=8+7) DecoderStream 2.00 ± 0% 2.00 ± 0% ~ (all equal) DecoderStream-6 2.00 ± 0% 2.00 ± 0% ~ (all equal) DecoderStream-48 2.00 ± 0% 2.00 ± 0% ~ (all equal) CodeUnmarshal 105k ± 0% 105k ± 0% ~ (all equal) CodeUnmarshal-6 105k ± 0% 105k ± 0% ~ (all equal) CodeUnmarshal-48 105k ± 0% 105k ± 0% ~ (all equal) CodeUnmarshalReuse 89.5k ± 0% 89.6k ± 0% ~ (p=0.246 n=7+8) CodeUnmarshalReuse-6 89.8k ± 0% 89.8k ± 0% ~ (p=1.000 n=8+8) CodeUnmarshalReuse-48 90.5k ± 0% 90.5k ± 0% ~ (all equal) UnmarshalString 2.00 ± 0% 2.00 ± 0% ~ (all equal) UnmarshalString-6 2.00 ± 0% 2.00 ± 0% ~ (all equal) UnmarshalString-48 2.00 ± 0% 2.00 ± 0% ~ (all equal) UnmarshalFloat64 2.00 ± 0% 2.00 ± 0% ~ (all equal) UnmarshalFloat64-6 2.00 ± 0% 2.00 ± 0% ~ (all equal) UnmarshalFloat64-48 2.00 ± 0% 2.00 ± 0% ~ (all equal) UnmarshalInt64 2.00 ± 0% 2.00 ± 0% ~ (all equal) UnmarshalInt64-6 2.00 ± 0% 2.00 ± 0% ~ (all equal) UnmarshalInt64-48 2.00 ± 0% 2.00 ± 0% ~ (all equal) Issue10335 3.00 ± 0% 3.00 ± 0% ~ (all equal) Issue10335-6 3.00 ± 0% 3.00 ± 0% ~ (all equal) Issue10335-48 3.00 ± 0% 3.00 ± 0% ~ (all equal) Unmapped 4.00 ± 0% 4.00 ± 0% ~ (all equal) Unmapped-6 4.00 ± 0% 4.00 ± 0% ~ (all equal) Unmapped-48 4.00 ± 0% 4.00 ± 0% ~ (all equal) NumberIsValid 0.00 0.00 ~ (all equal) NumberIsValid-6 0.00 0.00 ~ (all equal) NumberIsValid-48 0.00 0.00 ~ (all equal) NumberIsValidRegexp 0.00 0.00 ~ (all equal) NumberIsValidRegexp-6 0.00 0.00 ~ (all equal) NumberIsValidRegexp-48 0.00 0.00 ~ (all equal) SkipValue 0.00 0.00 ~ (all equal) SkipValue-6 0.00 0.00 ~ (all equal) SkipValue-48 0.00 0.00 ~ (all equal) EncoderEncode 1.00 ± 0% 0.00 -100.00% (p=0.000 n=8+8) EncoderEncode-6 1.00 ± 0% 0.00 -100.00% (p=0.000 n=8+8) EncoderEncode-48 1.00 ± 0% 0.00 -100.00% (p=0.000 n=8+8) https://perf.golang.org/search?q=upload:20170427.2 updates #17973 updates #18177 Change-Id: I5881c7a2bfad1766e6aa3444bb630883e0be467b Reviewed-on: https://go-review.googlesource.com/41931 Run-TryBot: Bryan Mills <bcmills@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
* encoding/json: parallelize most benchmarksBryan C. Mills2017-04-262-63/+83
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Don't bother with BenchmarkDecoderStream — it's doing something subtle with the input buffer that isn't easy to replicate in a parallel test. Results remain comparable with the non-parallel version with -cpu=1: benchmark old ns/op new ns/op delta BenchmarkCodeEncoder 22815832 21058729 -7.70% BenchmarkCodeEncoder-6 22190561 3579757 -83.87% BenchmarkCodeMarshal 25356621 25396429 +0.16% BenchmarkCodeMarshal-6 25359813 4944908 -80.50% BenchmarkCodeDecoder 94794556 88016360 -7.15% BenchmarkCodeDecoder-6 93795028 16726283 -82.17% BenchmarkDecoderStream 532 583 +9.59% BenchmarkDecoderStream-6 598 550 -8.03% BenchmarkCodeUnmarshal 97644168 89162504 -8.69% BenchmarkCodeUnmarshal-6 96615302 17036419 -82.37% BenchmarkCodeUnmarshalReuse 91747073 90298479 -1.58% BenchmarkCodeUnmarshalReuse-6 89397165 15518005 -82.64% BenchmarkUnmarshalString 808 843 +4.33% BenchmarkUnmarshalString-6 912 220 -75.88% BenchmarkUnmarshalFloat64 695 732 +5.32% BenchmarkUnmarshalFloat64-6 710 191 -73.10% BenchmarkUnmarshalInt64 635 640 +0.79% BenchmarkUnmarshalInt64-6 618 185 -70.06% BenchmarkIssue10335 916 947 +3.38% BenchmarkIssue10335-6 879 216 -75.43% BenchmarkNumberIsValid 34.7 34.3 -1.15% BenchmarkNumberIsValid-6 34.9 36.7 +5.16% BenchmarkNumberIsValidRegexp 1174 1121 -4.51% BenchmarkNumberIsValidRegexp-6 1134 1119 -1.32% BenchmarkSkipValue 20506938 20708060 +0.98% BenchmarkSkipValue-6 21627665 22375630 +3.46% BenchmarkEncoderEncode 690 726 +5.22% BenchmarkEncoderEncode-6 649 157 -75.81% benchmark old MB/s new MB/s speedup BenchmarkCodeEncoder 85.05 92.15 1.08x BenchmarkCodeEncoder-6 87.45 542.07 6.20x BenchmarkCodeMarshal 76.53 76.41 1.00x BenchmarkCodeMarshal-6 76.52 392.42 5.13x BenchmarkCodeDecoder 20.47 22.05 1.08x BenchmarkCodeDecoder-6 20.69 116.01 5.61x BenchmarkCodeUnmarshal 19.87 21.76 1.10x BenchmarkCodeUnmarshal-6 20.08 113.90 5.67x BenchmarkSkipValue 90.55 89.67 0.99x BenchmarkSkipValue-6 90.83 87.80 0.97x benchmark old allocs new allocs delta BenchmarkIssue10335 4 4 +0.00% BenchmarkIssue10335-6 4 4 +0.00% BenchmarkEncoderEncode 1 1 +0.00% BenchmarkEncoderEncode-6 1 1 +0.00% benchmark old bytes new bytes delta BenchmarkIssue10335 320 320 +0.00% BenchmarkIssue10335-6 320 320 +0.00% BenchmarkEncoderEncode 8 8 +0.00% BenchmarkEncoderEncode-6 8 8 +0.00% updates #18177 Change-Id: Ia4f5bf5ac0afbadb1705ed9f9e1b39dabba67b40 Reviewed-on: https://go-review.googlesource.com/36724 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
* encoding/json: reduce unmarshal mallocs for unmapped fieldsPascal S. de Kloe2017-03-202-34/+39
| | | | | | | | | | | | | | | | | | | | | | | | | | JSON decoding performs poorly for unmapped and ignored fields. We noticed better performance when unmarshalling unused fields. The loss comes mostly from calls to scanner.error as described at #17914. benchmark old ns/op new ns/op delta BenchmarkIssue10335-8 431 408 -5.34% BenchmarkUnmapped-8 1744 1314 -24.66% benchmark old allocs new allocs delta BenchmarkIssue10335-8 4 3 -25.00% BenchmarkUnmapped-8 18 4 -77.78% benchmark old bytes new bytes delta BenchmarkIssue10335-8 320 312 -2.50% BenchmarkUnmapped-8 568 344 -39.44% Fixes #17914, improves #10335 Change-Id: I7d4258a94eb287c0fe49e7334795209b90434cd0 Reviewed-on: https://go-review.googlesource.com/33276 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
* encoding/json: clarify documention for Unmarshal into a pointer.Tuo Shan2017-02-101-1/+2
| | | | | | | | Fixes #18730. Change-Id: If3ef28e62f7e449d4c8dc1dfd78f7d6f5a87ed26 Reviewed-on: https://go-review.googlesource.com/36478 Reviewed-by: Russ Cox <rsc@golang.org>
* encoding/json: add Valid for checking validity of input bytesMatt Layher2017-02-072-0/+25
| | | | | | | | | | Fixes #18086 Change-Id: Idc501dd37893e04a01c6ed9920147d24c0c1fa18 Reviewed-on: https://go-review.googlesource.com/34202 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
* encoding/json: document what happens to MarshalText's resultRuss Cox2016-11-221-1/+1
| | | | | | | | | | | Fixes #17743. Change-Id: Ib5afb6248bb060f2ad8dd3d5f78e95271af62a57 Reviewed-on: https://go-review.googlesource.com/33135 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Quentin Smith <quentin@golang.org> Reviewed-by: Caleb Spare <cespare@gmail.com>
* all: spell "marshal" and "unmarshal" consistentlyDmitri Shuralyov2016-11-122-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The tree is inconsistent about single l vs double l in those words in documentation, test messages, and one error value text. $ git grep -E '[Mm]arshall(|s|er|ers|ed|ing)' | wc -l 42 $ git grep -E '[Mm]arshal(|s|er|ers|ed|ing)' | wc -l 1694 Make it consistently a single l, per earlier decisions. This means contributors won't be confused by misleading precedence, and it helps consistency. Change the spelling in one error value text in newRawAttributes of crypto/x509 package to be consistent. This change was generated with: perl -i -npe 's,([Mm]arshal)l(|s|er|ers|ed|ing),$1$2,' $(git grep -l -E '[Mm]arshall' | grep -v AUTHORS | grep -v CONTRIBUTORS) Updates #12431. Follows https://golang.org/cl/14150. Change-Id: I85d28a2d7692862ccb02d6a09f5d18538b6049a2 Reviewed-on: https://go-review.googlesource.com/33017 Run-TryBot: Minux Ma <minux@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
* encoding/json: encode nil Marshaler as "null"Emmanuel Odeke2016-11-112-1/+43
| | | | | | | | | | Fixes #16042. Change-Id: I0a28aa004246b7b0ffaaab457e077ad9035363c2 Reviewed-on: https://go-review.googlesource.com/31932 Reviewed-by: Russ Cox <rsc@golang.org> Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
* all: sprinkle t.Parallel on some slow testsBrad Fitzpatrick2016-11-042-0/+3
| | | | | | | | | | | | | | | | | I used the slowtests.go tool as described in https://golang.org/cl/32684 on packages that stood out. go test -short std drops from ~56 to ~52 seconds. This isn't a huge win, but it was mostly an exercise. Updates #17751 Change-Id: I9f3402e36a038d71e662d06ce2c1d52f6c4b674d Reviewed-on: https://go-review.googlesource.com/32751 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
* encoding/json: example on MarshalJSON, UnmarshalJSONEmmanuel Odeke2016-11-031-0/+73
| | | | | | | | | | Updates #16360. Change-Id: I5bf13d3367e68c5d8435f6ef2161d5a74cc747a7 Reviewed-on: https://go-review.googlesource.com/29611 Reviewed-by: Andrew Gerrand <adg@golang.org> Run-TryBot: Andrew Gerrand <adg@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
* encoding/json: marshal with null when RawMessage is nilJoe Tsai2016-11-012-33/+100
| | | | | | | | | | | | | | | | | | This CL expands upon a change made in (http://golang.org/cl/21811) to ensure that a nil RawMessage gets serialized as "null" instead of being a nil slice. The added check only triggers when the RawMessage is nil. We do not handle the case when the RawMessage is non-nil, but empty. Fixes #17704 Updates #14493 Change-Id: I0fbebcdd81f7466c5b78c94953afc897f162ceb4 Reviewed-on: https://go-review.googlesource.com/32472 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
* encoding/json: marshal the RawMessage value type the same as its pointer typeBrad Fitzpatrick2016-10-262-4/+17
| | | | | | | | | | | Fixes #14493 Updates #6458 (changes its behavior) Change-Id: I851a8113fd312dae3384e989ec2b70949dc22838 Reviewed-on: https://go-review.googlesource.com/21811 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Quentin Smith <quentin@golang.org>
* encoding/json: fix bad formatting introduced in CL 20356Russ Cox2016-10-241-2/+2
| | | | | | | Change-Id: I39a8b543e472e5ec5d4807a9b7f61657465c5ce5 Reviewed-on: https://go-review.googlesource.com/31816 Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
* encoding/json: fix decoding of null into Unmarshaler, TextUnmarshalerRuss Cox2016-10-172-37/+219
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 1. Define behavior for Unmarshal of JSON null into Unmarshaler and TextUnmarshaler. Specifically, an Unmarshaler will be given the literal null and can decide what to do (because otherwise json.RawMessage is impossible to implement), and a TextUnmarshaler will be skipped over (because there is no text to unmarshal), like most other inappropriate types. Document this in Unmarshal, with a reminder in UnmarshalJSON about handling null. 2. Test all this. 3. Fix the TextUnmarshaler case, which was returning an unmarshalling error, to match the definition. 4. Fix the error that had been used for the TextUnmarshaler, since it was claiming that there was a JSON string when in fact the problem was NOT having a string. 5. Adjust time.Time and big.Int's UnmarshalJSON to ignore null, as is conventional. Fixes #9037. Change-Id: If78350414eb8dda712867dc8f4ca35a9db041b0c Reviewed-on: https://go-review.googlesource.com/30944 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
* encoding/json: handle misspelled JSON literals in ,stringRuss Cox2016-10-132-1/+27
| | | | | | | | | | Fixes #15146. Change-Id: I229611b9cc995a1391681c492c4d742195c787ea Reviewed-on: https://go-review.googlesource.com/30943 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
* encoding/json: explicitly document and test "-" key tagRichard Gibson2016-10-062-12/+32
| | | | | | | | | | | | Struct fields can be suppressed in JSON serialization by "-" tags, but that doesn't preclude generation of "-" object keys. Document and verify the mechanism for doing so. Change-Id: I7f60e1759cfee15cb7b2447cd35fab91c5b004e6 Reviewed-on: https://go-review.googlesource.com/21204 Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
* encoding/json: add struct and field name to UnmarshalTypeError messageJirka Daněk2016-10-052-34/+90
| | | | | | | | | | | | | | The UnmarshalTypeError has two new fields Struct and Field, used when constructing the error message. Fixes #6716. Change-Id: I67da171480a9491960b3ae81893770644180f848 Reviewed-on: https://go-review.googlesource.com/18692 Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by: Russ Cox <rsc@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
* encoding/json: use standard ES6 formatting for numbers during marshalRuss Cox2016-10-053-1/+143
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Change float32/float64 formatting to use non-exponential form for a slightly wider range, to more closely match ES6 JSON.stringify and other JSON generators. Most notably: 1e20 now formats as 100000000000000000000 (previously 1e+20) 1e-6 now formats as 0.000001 (previously 1e-06) 1e-7 now formats as 1e-7 (previously 1e-07) This also brings the int64 and float64 formatting in line with each other, for all shared representable values. For example both int64(1234567) and float64(1234567) now format as "1234567", where before the float64 formatted as "1.234567e+06". The only variation now compared to ES6 JSON.stringify is that Go continues to encode negative zero as "-0", not "0", so that the value continues to be preserved during JSON round trips. Fixes #6384. Fixes #14135. Change-Id: Ib0e0e009cd9181d75edc0424a28fe776bcc5bbf8 Reviewed-on: https://go-review.googlesource.com/30371 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
* all: use sort.Slice where applicableBrad Fitzpatrick2016-10-041-33/+17
| | | | | | | | | | | | | | | | | I avoided anywhere in the compiler or things which might be used by the compiler in the future, since they need to build with Go 1.4. I also avoided anywhere where there was no benefit to changing it. I probably missed some. Updates #16721 Change-Id: Ib3c895ff475c6dec2d4322393faaf8cb6a6d4956 Reviewed-on: https://go-review.googlesource.com/30250 TryBot-Result: Gobot Gobot <gobot@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Andrew Gerrand <adg@golang.org>
* encoding/json: fix a bug in the documentationmike andrews2016-09-271-1/+2
| | | | | | | | | | | Documentation made reference to an unknown entity "DisableHTMLEscaping," but I think it actually meant the method "Encoder.SetEscapeHTML." Fixes #17255 Change-Id: I18fda76f8066110caef85fd33698de83d632e646 Reviewed-on: https://go-review.googlesource.com/29931 Reviewed-by: Ian Lance Taylor <iant@golang.org>
* encoding/json: Use a lookup table for safe charactersKevin Burke2016-09-082-4/+220
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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/24466 Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com> Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
* encoding/json: add example for RawMessage marshallingCarlos C2016-08-161-1/+25
| | | | | | | | | | Fixes #16648 Change-Id: I3ab21ab33ca3f41219de9518ac6a39f49131e5e5 Reviewed-on: https://go-review.googlesource.com/26692 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
* encoding/json: copy-on-write cacheTypeFieldsDavid Crawshaw2016-06-271-10/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | Swtich from a sync.RWMutex to atomic.Value for cacheTypeFields. On GOARCH=386, this recovers most of the remaining performance difference from the 1.6 release. Compared with tip on linux/386: name old time/op new time/op delta CodeDecoder-40 92.8ms ± 1% 87.7ms ± 1% -5.50% (p=0.000 n=10+10) name old speed new speed delta CodeDecoder-40 20.9MB/s ± 1% 22.1MB/s ± 1% +5.83% (p=0.000 n=10+10) With more time and care, I believe more of the JSON decoder's work could be shifted so it is done before decoding, and independent of the number of bytes processed. Maybe someone could explore that for Go 1.8. For #16117. Change-Id: I049655b2e5b76384a0d5f4b90e3ec7cc8d8c4340 Reviewed-on: https://go-review.googlesource.com/24472 Run-TryBot: Dmitry Vyukov <dvyukov@google.com> Reviewed-by: Dmitry Vyukov <dvyukov@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
* encoding/json: fix docs on valid key namesDavid Glasser2016-06-031-2/+2
| | | | | | | | | | | | This has been inaccurate since https://golang.org/cl/6048047. Fixes #15317. Change-Id: If93d2161f51ccb91912cb94a35318cf33f4d526a Reviewed-on: https://go-review.googlesource.com/23691 Reviewed-by: Ian Lance Taylor <iant@golang.org> Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
* encoding/json: improve Decode exampleQuentin Smith2016-05-261-2/+1
| | | | | | | | | | | | Decoding a JSON message does not touch unspecified or null fields; always use a new underlying struct to prevent old field values from sticking around. Fixes: #14640 Change-Id: Ica78c208ce104e2cdee1d4e92bf58596ea5587c8 Reviewed-on: https://go-review.googlesource.com/23483 Reviewed-by: Andrew Gerrand <adg@golang.org>
* encoding/json: rename Indent method to SetIndentRuss Cox2016-05-242-6/+13
| | | | | | | | | | | | | | | | | | | | | CL 21057 added this method during the Go 1.7 cycle (so it is not yet released and still possible to revise). This makes it clearer that the method is not doing something (like func Indent does), but just changing a setting about doing something later. Also document that this is in some sense irreversible. I think that's probably a mistake but the original CL discussion claimed it as a feature, so I'll leave it alone. For #6492. Change-Id: If4415c869a9196501056c143811a308822d5a420 Reviewed-on: https://go-review.googlesource.com/23295 Reviewed-by: Ian Lance Taylor <iant@golang.org> Reviewed-by: Andrew Gerrand <adg@golang.org> Run-TryBot: Russ Cox <rsc@golang.org>
* encoding/json: change DisableHTMLEscaping to SetEscapeHTMLRuss Cox2016-05-242-8/+13
| | | | | | | | | | | | DisableHTMLEscaping is now SetEscapeHTML, allowing the escaping to be toggled, not just disabled. This API is new for Go 1.7, so there are no compatibility concerns (quite the opposite, the point is to fix the API before we commit to it in Go 1.7). Change-Id: I96b9f8f169a9c44995b8a157a626eb62d0b6dea7 Reviewed-on: https://go-review.googlesource.com/23293 Reviewed-by: Ian Lance Taylor <iant@golang.org> Reviewed-by: Andrew Gerrand <adg@golang.org>
* encoding/json: additional tests and fixes for []typedByte encoding/decodingRuss Cox2016-05-242-13/+208
| | | | | | | | | | | | | | | | | | | | | | CL 19725 changed the encoding of []typedByte to look for typedByte.MarshalJSON and typedByte.MarshalText. Previously it was handled like []byte, producing a base64 encoding of the underlying byte data. CL 19725 forgot to look for (*typedByte).MarshalJSON and (*typedByte).MarshalText, as the marshaling of other slices would. Add test and fix for those. This CL also adds tests that the decoder can handle both the old and new encodings. (This was true even in Go 1.6, which is the only reason we can consider this not an incompatible change.) For #13783. Change-Id: I7cab8b6c0154a7f2d09335b7fa23173bcf856c37 Reviewed-on: https://go-review.googlesource.com/23294 Reviewed-by: Ian Lance Taylor <iant@golang.org> Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Andrew Gerrand <adg@golang.org>
* encoding/json: document that object keys are sortedScott Bell2016-05-161-2/+2
| | | | | | | | Fixes #15424 Change-Id: Ib9e97509f5ac239ee54fe6fe37152a7f5fc75087 Reviewed-on: https://go-review.googlesource.com/23109 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
* encoding/json: support maps with integer keysCaleb Spare2016-05-103-22/+158
| | | | | | | | | | | | | | | | | | | | This change makes encoding and decoding support integer types in map keys, converting to/from JSON string keys. JSON object keys are still sorted lexically, even though the keys may be integer strings. For backwards-compatibility, the existing Text(Un)Marshaler support for map keys (added in CL 20356) does not take precedence over the default encoding for string types. There is no such concern for integer types, so integer map key encoding is only used as a fallback if the map key type is not a Text(Un)Marshaler. Fixes #12529. Change-Id: I7e68c34f9cd19704b1d233a9862da15fabf0908a Reviewed-on: https://go-review.googlesource.com/22060 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
* encoding/json: add Encoder.DisableHTMLEscapingCaleb Spare2016-04-224-93/+150
| | | | | | | | | | | | | This provides a way to disable the escaping of <, >, and & in JSON strings. Fixes #14749. Change-Id: I1afeb0244455fc8b06c6cce920444532f229555b Reviewed-on: https://go-review.googlesource.com/21796 Run-TryBot: Caleb Spare <cespare@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
* encoding/json: update docs to not use misuse the term "object"Brad Fitzpatrick2016-04-163-11/+11
| | | | | | | | | | | | | In JSON terminology, "object" is a collect of key/value pairs. But a JSON object is only one type of JSON value (others are string, number, array, true, false, null). This updates the Go docs (at least the public godoc) to not use "object" when we mean any JSON value. Change-Id: Ieb1c456c703693714d63d9d09d306f4d9e8f4597 Reviewed-on: https://go-review.googlesource.com/22003 Reviewed-by: Andrew Gerrand <adg@golang.org>
* encoding/json: respect json.Marshaler when encoding byte kind slicesHåvard Haugen2016-04-062-1/+58
| | | | | | | | | | Fixes #13783. Change-Id: I0122c1f0cf4075acabf5f58241bded1835699dc1 Reviewed-on: https://go-review.googlesource.com/19725 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
* encoding/json: allow non-string type keys for (un-)marshalAugusto Roman2016-04-054-40/+123
| | | | | | | | | | | | | | | | This CL allows JSON-encoding & -decoding maps whose keys are types that implement encoding.TextMarshaler / TextUnmarshaler. During encode, the map keys are marshaled upfront so that they can be sorted. Fixes #12146 Change-Id: I43809750a7ad82a3603662f095c7baf75fd172da Reviewed-on: https://go-review.googlesource.com/20356 Run-TryBot: Caleb Spare <cespare@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
* all: zero mtimes in testdata gz filesCaleb Spare2016-03-251-0/+0
| | | | | | | | | | Fixes #14937. Change-Id: Iea11a32230d44d5a43f8aec812d25f13bce85895 Reviewed-on: https://go-review.googlesource.com/21038 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
* encoding/json: add (*Encoder).IndentCaleb Spare2016-03-252-1/+51
| | | | | | | | | Fixes #6492. Change-Id: Ibc633c43a6d134bb140addb59780a5758b35a5c5 Reviewed-on: https://go-review.googlesource.com/21057 Run-TryBot: Caleb Spare <cespare@gmail.com> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
* encoding/json, internal/testenv: use FatalfDominik Honnef2016-03-221-1/+1
| | | | | | Change-Id: I64dd09e76d811000a914776fdad47808e3895690 Reviewed-on: https://go-review.googlesource.com/20989 Reviewed-by: Dave Cheney <dave@cheney.net>
* all: single space after period.Brad Fitzpatrick2016-03-024-9/+9
| | | | | | | | | | | | | | | | | | | | The tree's pretty inconsistent about single space vs double space after a period in documentation. Make it consistently a single space, per earlier decisions. This means contributors won't be confused by misleading precedence. This CL doesn't use go/doc to parse. It only addresses // comments. It was generated with: $ perl -i -npe 's,^(\s*// .+[a-z]\.) +([A-Z]),$1 $2,' $(git grep -l -E '^\s*//(.+\.) +([A-Z])') $ go test go/doc -update Change-Id: Iccdb99c37c797ef1f804a94b22ba5ee4b500c4f7 Reviewed-on: https://go-review.googlesource.com/20022 Reviewed-by: Rob Pike <r@golang.org> Reviewed-by: Dave Day <djd@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
* all: make copyright headers consistent with one space after periodBrad Fitzpatrick2016-03-0111-11/+11
| | | | | | | | | | | | | | | | | | | | | | This is a subset of https://golang.org/cl/20022 with only the copyright header lines, so the next CL will be smaller and more reviewable. Go policy has been single space after periods in comments for some time. The copyright header template at: https://golang.org/doc/contribute.html#copyright also uses a single space. Make them all consistent. Change-Id: Icc26c6b8495c3820da6b171ca96a74701b4a01b0 Reviewed-on: https://go-review.googlesource.com/20111 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
* all: fix typos and spellingMartin Möhrmann2016-02-241-2/+2
| | | | | | | | Change-Id: Icd06d99c42b8299fd931c7da821e1f418684d913 Reviewed-on: https://go-review.googlesource.com/19829 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
* encoding/json: doc: Decode only writes to exported fieldsIan Lance Taylor2016-01-081-0/+1
| | | | | | | | Fixes #13867. Change-Id: I6c0a6c64369681840df60f63036c2eece27de8b8 Reviewed-on: https://go-review.googlesource.com/18394 Reviewed-by: Russ Cox <rsc@golang.org>
* encoding/json: document Indent's preservation of trailing spacesRuss Cox2015-12-081-2/+6
| | | | | | | | Fixes #13520. Change-Id: Ia70cc44be3912167b369d7f74d3436331975c300 Reviewed-on: https://go-review.googlesource.com/17561 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
* encoding/json: streamline, unexport valid Number checkingRuss Cox2015-12-043-101/+44
| | | | | | | | | | Followup to CL 12250. For #10281. Change-Id: If25d9cac92f10327bb355f2d11b00c625b464661 Reviewed-on: https://go-review.googlesource.com/17199 Reviewed-by: Ian Lance Taylor <iant@golang.org>
* encoding/json: revise docs for Unmarshal into map, slice, arrayRuss Cox2015-12-031-5/+15
| | | | | | | | Fixes #12972. Change-Id: Id0611667e6149753c351c0c5e01211340a87d3fd Reviewed-on: https://go-review.googlesource.com/17230 Reviewed-by: David Crawshaw <crawshaw@golang.org>
* encoding/json: check if Number is validErik Dubbelboer2015-11-254-0/+271
| | | | | | | | | | json.Number is a special case which didn't have any checks and could result in invalid JSON. Fixes #10281 Change-Id: Ie3e726e4d6bf6a6aba535d36f6107013ceac913a Reviewed-on: https://go-review.googlesource.com/12250 Reviewed-by: Russ Cox <rsc@golang.org>
View Lorry Controller Status