| Age | Commit message (Collapse) | Author |
|
Do not panic when we encounter nil interface values which are
invalid values for gob. Previously this wasn't caught yet
we were calling reflect.*.Type() on reflect.Invalid values
thereby causing panic:
`panic: reflect: call of reflect.Value.Type on zero Value.`
which is a panic not enforced by encoding/gob itself.
We can catch this and send back an error to the caller.
Fixes #16204
Change-Id: Ie646796db297759a74a02eee5267713adbe0c3a0
Reviewed-on: https://go-review.googlesource.com/24989
Reviewed-by: Rob Pike <r@golang.org>
Run-TryBot: Rob Pike <r@golang.org>
|
|
Fixes #16258.
Docs for Encode and EncodeValue do not mention that
nil pointers are not permitted hence we panic,
because Gobs encode values yet nil pointers have no value
to encode. It moves a comment that was internal to EncodeValue
to the top level to make it clearer to users what to expect
when they pass in nil pointers.
Supplements test TestTopLevelNilPointer.
Change-Id: Ie54f609fde4b791605960e088456047eb9aa8738
Reviewed-on: https://go-review.googlesource.com/24740
Reviewed-by: Andrew Gerrand <adg@golang.org>
Run-TryBot: Andrew Gerrand <adg@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
|
|
On linux/386 compared to tip:
name old time/op new time/op delta
DecodeInterfaceSlice-40 1.23ms ± 1% 1.17ms ± 1% -4.93% (p=0.000 n=9+10)
Recovers about half the performance regression from Go 1.6 on 386.
For #16117.
Change-Id: Ie8676d92a4da3e27ff21b91a98b3e13d16730ba1
Reviewed-on: https://go-review.googlesource.com/24468
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
|
|
Fixes #15570
Change-Id: I95d1ac26e342c3bbf36ad1f0209711ea96eaf487
Reviewed-on: https://go-review.googlesource.com/22870
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
|
|
Fixes #13808.
Change-Id: Ifbd5644da995a812438a405485c9e08b4503a313
Reviewed-on: https://go-review.googlesource.com/22352
Reviewed-by: Ian Lance Taylor <iant@golang.org>
|
|
cmd and runtime were handled separately, and I'm intentionally skipped
syscall. This is the rest of the standard library.
CL generated mechanically with github.com/mdempsky/unconvert.
Change-Id: I9e0eff886974dedc37adb93f602064b83e469122
Reviewed-on: https://go-review.googlesource.com/22104
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
|
|
This deletes unused code and helpers from tests.
Change-Id: Ie31d46115f558ceb8da6efbf90c3c204e03b0d7e
Reviewed-on: https://go-review.googlesource.com/20927
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
|
|
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>
|
|
Change-Id: Ia613f1c37bfce800ece0533a5326fca91d99a66a
Reviewed-on: https://go-review.googlesource.com/18120
Reviewed-by: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
|
|
The documentation was inconsistent. It said zero values were not sent, but
that zero-valued elements of arrays and arrays were sent. But which rule
applies if the array is all zero elements, and is therefore itself a zero value?
The answer is: the array is transmitted. In principle the other choice could
be made, but there would be considerable expense and complexity required
to implement this behavior now, not to mention worries about changes of
behavior.
Therefore we just document the situation: Arrays, slices, and maps are
always encoded. It would perhaps be nice to have sorted this out earlier,
but it was a missed opportunity.
Fixes #13378
Change-Id: I8fae345edfa707fcfa7a3e0160d87ff1ac5cc5a2
Reviewed-on: https://go-review.googlesource.com/17394
Reviewed-by: Russ Cox <rsc@golang.org>
|
|
Benchmark results:
benchmark old ns/op new ns/op delta
BenchmarkEndToEndPipe-4 7547 7294 -3.35%
BenchmarkEndToEndByteBuffer-4 5146 5092 -1.05%
BenchmarkEndToEndSliceByteBuffer-4 552779 439768 -20.44%
BenchmarkEncodeComplex128Slice-4 266370 266184 -0.07%
BenchmarkEncodeFloat64Slice-4 111891 110258 -1.46%
BenchmarkEncodeInt32Slice-4 74482 74080 -0.54%
BenchmarkEncodeStringSlice-4 84404 84279 -0.15%
BenchmarkEncodeInterfaceSlice-4 3942925 3045995 -22.75%
BenchmarkDecodeComplex128Slice-4 451837 415282 -8.09%
BenchmarkDecodeFloat64Slice-4 283584 262558 -7.41%
BenchmarkDecodeInt32Slice-4 246571 237383 -3.73%
BenchmarkDecodeStringSlice-4 734210 479625 -34.67%
BenchmarkDecodeInterfaceSlice-4 4778225 4160935 -12.92%
benchmark old allocs new allocs delta
BenchmarkEndToEndPipe-4 3 2 -33.33%
BenchmarkEndToEndByteBuffer-4 3 2 -33.33%
BenchmarkEndToEndSliceByteBuffer-4 1002 402 -59.88%
BenchmarkEncodeComplex128Slice-4 1 1 +0.00%
BenchmarkEncodeFloat64Slice-4 1 1 +0.00%
BenchmarkEncodeInt32Slice-4 1 1 +0.00%
BenchmarkEncodeStringSlice-4 1 1 +0.00%
BenchmarkEncodeInterfaceSlice-4 3001 1 -99.97%
BenchmarkDecodeComplex128Slice-4 188 185 -1.60%
BenchmarkDecodeFloat64Slice-4 188 185 -1.60%
BenchmarkDecodeInt32Slice-4 188 185 -1.60%
BenchmarkDecodeStringSlice-4 2188 1185 -45.84%
BenchmarkDecodeInterfaceSlice-4 6197 4194 -32.32%
benchmark old bytes new bytes delta
BenchmarkEndToEndPipe-4 64 48 -25.00%
BenchmarkEndToEndByteBuffer-4 64 48 -25.00%
BenchmarkEndToEndSliceByteBuffer-4 34551 10554 -69.45%
BenchmarkEncodeComplex128Slice-4 55 55 +0.00%
BenchmarkEncodeFloat64Slice-4 33 33 +0.00%
BenchmarkEncodeInt32Slice-4 32 32 +0.00%
BenchmarkEncodeStringSlice-4 36 36 +0.00%
BenchmarkEncodeInterfaceSlice-4 144555 347 -99.76%
BenchmarkDecodeComplex128Slice-4 28240 28097 -0.51%
BenchmarkDecodeFloat64Slice-4 11840 11697 -1.21%
BenchmarkDecodeInt32Slice-4 10817 10673 -1.33%
BenchmarkDecodeStringSlice-4 56128 39985 -28.76%
BenchmarkDecodeInterfaceSlice-4 132565 100421 -24.25%
Change-Id: Ief7c7706b1f2916486ab7190b81aafbb16b70f1e
Reviewed-on: https://go-review.googlesource.com/13660
Reviewed-by: Russ Cox <rsc@golang.org>
|
|
Fixes #13378
Change-Id: Ia78624ca1aa36ee906cef15416ea5554fa8229f2
Reviewed-on: https://go-review.googlesource.com/17201
Reviewed-by: Ian Lance Taylor <iant@golang.org>
|
|
Change-Id: I6a882d9f0bc20b7a8bf73765e055d9344f3f401f
Reviewed-on: https://go-review.googlesource.com/15422
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
|
|
This is understood, obvious (to me), and well known but has not been clearly documented.
Fixes #11117.
Change-Id: Ib2b1e318924748d1eac0d735ad6286533be7fd39
Reviewed-on: https://go-review.googlesource.com/14693
Reviewed-by: Ian Lance Taylor <iant@golang.org>
|
|
This is not a functional change. nr is a uint64 and can never be less
than zero, remove the no-op comparison.
Fixes #11279
Change-Id: Iebb36cc8fe97428b503e65d01b5e67d2b2bc7369
Reviewed-on: https://go-review.googlesource.com/13876
Run-TryBot: Todd Neal <todd@tneal.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
|
|
Could go in 1.5, although not critical.
See also #12107
Change-Id: I7f1608b58581d21df4db58f0db654fef79e33a90
Reviewed-on: https://go-review.googlesource.com/13481
Reviewed-by: Dave Cheney <dave@cheney.net>
|
|
The previous commit (git 2ae77376) just did golang.org. This one
includes golang.org subdomains like blog, play, and build.
Change-Id: I4469f7b307ae2a12ea89323422044e604c5133ae
Reviewed-on: https://go-review.googlesource.com/12071
Reviewed-by: Rob Pike <r@golang.org>
|
|
This was a simple oversight: the algorithm to handle recursive types
needed to be applied to the ignore-item case as well.
Fixes #10415.
Change-Id: I39ef31cad680ab8334e141f60d2f8707896785d1
Reviewed-on: https://go-review.googlesource.com/8942
Reviewed-by: Dmitry Vyukov <dvyukov@google.com>
|
|
Fixes #10908.
Change-Id: I5ac4bd90204bc230610dcced47ce5b2253e5a004
Reviewed-on: https://go-review.googlesource.com/10250
Reviewed-by: Rob Pike <r@golang.org>
|
|
Messages that are too big are rejected when read, so they should
be rejected when written too.
Fixes #10518.
Change-Id: I96678fbe2d94f51b957fe26faef33cd8df3823dd
Reviewed-on: https://go-review.googlesource.com/9965
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
|
|
Change-Id: I4e59b5b1702e08d7c6191d0a70fb0a555f3340c8
Reviewed-on: https://go-review.googlesource.com/9061
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Rob Pike <r@golang.org>
|
|
Also unify the tests where possible to make it easy to add more.
Fixes #10273.
Change-Id: Idfa4f4a5dcaa05974066bafe17bed6cdd2ebedb7
Reviewed-on: https://go-review.googlesource.com/8662
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
|
|
When decoding an invalid typeId the associated *decEngine was not
removed from decoderMap. If the decoder was run again on the same input
a nil *decEngine was found in the map and assumed to be initialized,
resulting in a panic.
Fixes #9649
Change-Id: I5bb51808362a21c09228c2705a658f073e5b59b3
Reviewed-on: https://go-review.googlesource.com/3509
Reviewed-by: Rob Pike <r@golang.org>
|
|
Fix the other places the slice length was being believed, and refactor
the code to use a single function to unify the check.
Fixes #10273.
Change-Id: Ia62b25203fbe87c95d71a70ebc1db8d202eaa4a4
Reviewed-on: https://go-review.googlesource.com/8511
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
|
|
Change-Id: I6859bd9c9dba30fc5eeb9bbc1de90af67984944c
Reviewed-on: https://go-review.googlesource.com/8526
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
|
|
decBuffer.Drop is called using data provided by the user, don't
panic if it's bogus.
Fixes #10272.
Change-Id: I913ae9c3c45cef509f2b8eb02d1efa87fbd52afa
Reviewed-on: https://go-review.googlesource.com/8496
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
|
|
Use Fatalf for formatting directive rather than plain Fatal.
Change-Id: Iebd30cd6326890e9501746113a6d97480949e3d2
Reviewed-on: https://go-review.googlesource.com/2161
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
|
|
As we did with encoding, provide a trivial byte reader for
faster decoding. We can also reduce some of the copying
by doing the allocation all at once using a slightly different
interface from byte buffers.
benchmark old ns/op new ns/op delta
BenchmarkEndToEndPipe 13368 12902 -3.49%
BenchmarkEndToEndByteBuffer 5969 5642 -5.48%
BenchmarkEndToEndSliceByteBuffer 479485 470798 -1.81%
BenchmarkEncodeComplex128Slice 92367 92201 -0.18%
BenchmarkEncodeFloat64Slice 39990 38960 -2.58%
BenchmarkEncodeInt32Slice 30510 27938 -8.43%
BenchmarkEncodeStringSlice 33753 33365 -1.15%
BenchmarkDecodeComplex128Slice 232278 196704 -15.32%
BenchmarkDecodeFloat64Slice 150258 128191 -14.69%
BenchmarkDecodeInt32Slice 133806 115748 -13.50%
BenchmarkDecodeStringSlice 335117 300534 -10.32%
LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/154360049
|
|
Needed a %% to quote a percent in the format.
LGTM=adg
R=golang-codereviews, adg
CC=golang-codereviews
https://golang.org/cl/156330043
|
|
Bytes buffers have more API and are a little slower. Since appending
is a key part of the path in encode, using a faster implementation
speeds things up measurably.
The couple of positive swings are likely garbage-collection related
since memory allocation looks different in the benchmark now.
I am not concerned by them.
benchmark old ns/op new ns/op delta
BenchmarkEndToEndPipe 6620 6388 -3.50%
BenchmarkEndToEndByteBuffer 3548 3600 +1.47%
BenchmarkEndToEndSliceByteBuffer 336678 367980 +9.30%
BenchmarkEncodeComplex128Slice 78199 71297 -8.83%
BenchmarkEncodeFloat64Slice 37731 32258 -14.51%
BenchmarkEncodeInt32Slice 26780 22977 -14.20%
BenchmarkEncodeStringSlice 35882 26492 -26.17%
BenchmarkDecodeComplex128Slice 194819 185126 -4.98%
BenchmarkDecodeFloat64Slice 120538 120102 -0.36%
BenchmarkDecodeInt32Slice 106442 107275 +0.78%
BenchmarkDecodeStringSlice 272902 269866 -1.11%
LGTM=ruiu
R=golang-codereviews, ruiu
CC=golang-codereviews
https://golang.org/cl/160990043
|
|
Use go generate to write better loops for decoding arrays,
just as we did for encoding. It doesn't help as much,
relatively speaking, but it's still noticeable.
benchmark old ns/op new ns/op delta
BenchmarkDecodeComplex128Slice 202348 184529 -8.81%
BenchmarkDecodeFloat64Slice 135800 120979 -10.91%
BenchmarkDecodeInt32Slice 121200 105149 -13.24%
BenchmarkDecodeStringSlice 288129 278214 -3.44%
LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/154420044
|
|
We borrow a trick from the fmt package and avoid reflection
to walk the elements when possible. We could push further with
unsafe (and we may) but this is a good start.
Decode can benefit similarly; it will be done separately.
Use go generate (engen.go) to produce the helper functions
(enc_helpers.go).
benchmark old ns/op new ns/op delta
BenchmarkEndToEndPipe 6593 6482 -1.68%
BenchmarkEndToEndByteBuffer 3662 3684 +0.60%
BenchmarkEndToEndSliceByteBuffer 350306 351693 +0.40%
BenchmarkComplex128Slice 96347 80045 -16.92%
BenchmarkInt32Slice 42484 26008 -38.78%
BenchmarkFloat64Slice 51143 36265 -29.09%
BenchmarkStringSlice 53402 35077 -34.32%
LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/156310043
|
|
FieldByIndex never returns an invalid Value, so the validity
test can be avoided if the field is not indirect.
BenchmarkGobEncode 12768642 12424022 -2.70%
BenchmarkGobEncode 60.11 61.78 1.03x
LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/158890045
|
|
LGTM=ruiu
R=golang-codereviews, ruiu
CC=golang-codereviews
https://golang.org/cl/146320043
|
|
Fixes #8084.
LGTM=ruiu
R=golang-codereviews, ruiu
CC=golang-codereviews
https://golang.org/cl/142710043
|
|
Replace typeLock with copy-on-write map using atomic.Value.
benchmark old ns/op new ns/op delta
BenchmarkEndToEndPipe 7722 7709 -0.17%
BenchmarkEndToEndPipe-2 5114 4344 -15.06%
BenchmarkEndToEndPipe-4 3192 2429 -23.90%
BenchmarkEndToEndPipe-8 1833 1438 -21.55%
BenchmarkEndToEndPipe-16 1332 983 -26.20%
BenchmarkEndToEndPipe-32 1444 675 -53.25%
BenchmarkEndToEndByteBuffer 6474 6019 -7.03%
BenchmarkEndToEndByteBuffer-2 4280 2810 -34.35%
BenchmarkEndToEndByteBuffer-4 2264 1774 -21.64%
BenchmarkEndToEndByteBuffer-8 1275 979 -23.22%
BenchmarkEndToEndByteBuffer-16 1257 753 -40.10%
BenchmarkEndToEndByteBuffer-32 1342 644 -52.01%
BenchmarkEndToEndArrayByteBuffer 727725 671349 -7.75%
BenchmarkEndToEndArrayByteBuffer-2 394079 320473 -18.68%
BenchmarkEndToEndArrayByteBuffer-4 211785 178175 -15.87%
BenchmarkEndToEndArrayByteBuffer-8 141003 118857 -15.71%
BenchmarkEndToEndArrayByteBuffer-16 139249 86367 -37.98%
BenchmarkEndToEndArrayByteBuffer-32 144128 73454 -49.04%
LGTM=r
R=golang-codereviews, r
CC=golang-codereviews
https://golang.org/cl/147720043
|
|
Preparation was in CL 134570043.
This CL contains only the effect of 'hg mv src/pkg/* src'.
For more about the move, see golang.org/s/go14nopkg.
|