| Age | Commit message (Collapse) | Author |
|---|
|
This reduce the struct encodeState size from 56 to 16 bytes (-42),
struct structFields size from 40 to 24 bytes (-16), and struct field size
from 136 to 128 bytes (-8).
Benchmark memory profiling before and after,
File: json.test
Type: alloc_space
Time: Jan 25, 2024 at 4:51am (WIB)
Showing nodes accounting for -4.01GB, 4.66% of 85.95GB total
Dropped 64 nodes (cum <= 0.43GB)
flat flat% sum% cum cum%
-4.25GB 4.94% 4.94% -4.01GB 4.67% encoding/json.Marshal
0.19GB 0.22% 4.73% 0.24GB 0.28% encoding/json.mapEncoder.encode
0.05GB 0.057% 4.67% 0.05GB 0.057% reflect.copyVal
0.04GB 0.049% 4.62% 0.04GB 0.049% bytes.growSlice
-0.04GB 0.045% 4.66% -0.04GB 0.045% encoding/json.RawMessage.MarshalJSON
0 0% 4.66% 0.04GB 0.046% bytes.(*Buffer).WriteString
0 0% 4.66% 0.04GB 0.049% bytes.(*Buffer).grow
0 0% 4.66% -0.04GB 0.045% encoding/json.(*Encoder).Encode
0 0% 4.66% 0.20GB 0.23% encoding/json.(*encodeState).marshal
0 0% 4.66% 0.20GB 0.23% encoding/json.(*encodeState).reflectValue
|
|
This reduce the UnmarshalTypeError size from 64 to 56 bytes (-8 bytes),
and decodeState from 128 to 96 (-32 bytes).
|
|
Instead of re-slicing the string for checking the value, use single
index variable.
Benchmark result,
name old time/op new time/op delta
NumberIsValid-8 19.0ns ± 0% 14.5ns ± 1% -23.70% (p=0.008 n=5+5)
name old alloc/op new alloc/op delta
NumberIsValid-8 0.00B 0.00B ~ (all equal)
name old allocs/op new allocs/op delta
NumberIsValid-8 0.00 0.00 ~ (all equal)
Change-Id: I4698c5db134998f83ff47fb3add6a04ba6ec3aa0
|
|
Due to the lack of MarshalWrite in the v1 API,
it is unfortunately common to see:
json.NewEncoder(out).Encode(in)
where a single-use Encoder is constructed and thrown away.
This performed acceptably in v1 since every call to Encode
used a globally pooled encoder resource.
Prior to this change, the v1-in-v2 implementation relied
on a bytes.Buffer cached only for the lifetime of the Encoder
object itself. Thus, a single-use Encoder does not benefit.
Modify the wrapper implementation to use the internal
pooled encoder from v2 and use the intermediate buffer
to write directly to the output io.Writer.
We assume that the user-provided io.Writer never leaks the buffer,
but this assumption was already held in the v1 implementation.
We are not increasing the surface area of data corruption risk.
Performance of v1 to v1-in-v2 (before the pool fix):
name old time/op new time/op delta
NewEncoderEncode-32 30.2ms ± 4% 28.3ms ± 9% -6.19% (p=0.002 n=9+10)
name old alloc/op new alloc/op delta
NewEncoderEncode-32 7.64MB ± 0% 28.37MB ± 0% +271.23% (p=0.000 n=10+10)
name old allocs/op new allocs/op delta
NewEncoderEncode-32 200k ± 0% 100k ± 0% -49.99% (p=0.000 n=9+10)
Interestingly, v1-in-2 is slightly faster,
but the amount of allocated memory is massive.
Performance of v1 to v1-in-v2 (after the pool fix):
name old time/op new time/op delta
NewEncoderEncode-32 30.2ms ± 4% 24.0ms ± 7% -20.36% (p=0.000 n=9+10)
name old alloc/op new alloc/op delta
NewEncoderEncode-32 7.64MB ± 0% 4.09MB ± 3% -46.52% (p=0.000 n=10+10)
name old allocs/op new allocs/op delta
NewEncoderEncode-32 200k ± 0% 100k ± 0% -50.00% (p=0.000 n=9+9)
Now, the v1-in-v2 implementation is better than v1 on all metrics.
Fixes #75026
Change-Id: I50c975b1d5b8da806e46bc627966b0a39c1817eb
Reviewed-on: https://go-review.googlesource.com/c/go/+/740660
Reviewed-by: Michael Pratt <mpratt@google.com>
Reviewed-by: Damien Neil <dneil@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
|
|
tautological/impossible nil conditions
Change-Id: I3cdc599ebc93f5c9be5645e7ef7ce167242d9c1b
Reviewed-on: https://go-review.googlesource.com/c/go/+/739800
Reviewed-by: Roland Shoemaker <roland@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
|
|
Change-Id: Id5520757e4d73e56e533e4de4f5f303105c4339e
Reviewed-on: https://go-review.googlesource.com/c/go/+/738180
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Auto-Submit: David Symonds <dsymonds@golang.org>
Reviewed-by: Carlos Amedee <carlos@golang.org>
Reviewed-by: David Symonds <dsymonds@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Joseph Tsai <joetsai@digital-static.net>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
|
|
Followon for CL 721160.
Change-Id: I9c22c5e99c9084e24047c77d20717c5b46165cde
Reviewed-on: https://go-review.googlesource.com/c/go/+/732220
Reviewed-by: Carlos Amedee <carlos@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
Reviewed-by: Sean Liao <sean@liao.dev>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
|
|
The json/v2 working group decided to commit to no default representation
for time.Duration for the foreseeable future.
Thus, we can remove the issue reference in the error message.
If JavaScript (TC39) formally adopts the Temporal.Duration type,
which uses ISO 8601 as the JSON representation for a duration,
we may consider changing the default.
Switching from no default to some default in the future
is generally a compatible change.
Updates #71631
Change-Id: I6f71a0fa97dcefba56aab0c0ddf445d9d38f6e58
Reviewed-on: https://go-review.googlesource.com/c/go/+/735080
Reviewed-by: Michael Pratt <mpratt@google.com>
Reviewed-by: Damien Neil <dneil@google.com>
Auto-Submit: Joseph Tsai <joetsai@digital-static.net>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
|
|
The documentation on encoding/gob mentions that pointers are flattened,
and it also explicitly says that empty values are not sent.
A corollary of this, is that pointers to zero values are not sent, i.e.,
gob-encoding of *false becomes nil on the receiver side.
It is worth documenting this explicitly.
Change-Id: I1909203b8972e20791144bdda22e5f1b466aad97
GitHub-Last-Rev: 57764ec235ffe48484be98d3ed5269f0102ca4f8
GitHub-Pull-Request: golang/go#77009
Reviewed-on: https://go-review.googlesource.com/c/go/+/732820
Reviewed-by: Roland Shoemaker <roland@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Sean Liao <sean@liao.dev>
Reviewed-by: Cherry Mui <cherryyz@google.com>
|
|
Add constants for each possible Kind value (KindNull, KindTrue, etc.).
Leave the values unchanged ('n', 't', etc.).
Update documentation to reference the symbols.
Fixes #71756
Change-Id: Ib33b2ad9ee55f6f547d9e6a1c5a7f00c8400d3d3
Reviewed-on: https://go-review.googlesource.com/c/go/+/728420
Auto-Submit: Damien Neil <dneil@google.com>
Reviewed-by: Joseph Tsai <joetsai@digital-static.net>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
|
|
For #75431
Change-Id: Iafefe952d3c1837e2f4c8c24cae96945d9e5abbf
Reviewed-on: https://go-review.googlesource.com/c/go/+/728380
Reviewed-by: Joseph Tsai <joetsai@digital-static.net>
Auto-Submit: Damien Neil <dneil@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
|
|
Historically, Decoder.More reports true when the next read will
return an error. Adjust the v2 Decoder to follow this behavior.
Fixes #76467
Change-Id: I03bfa391e4e89ada8ca869db43c1d0bb63cc0413
Reviewed-on: https://go-review.googlesource.com/c/go/+/728300
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Auto-Submit: Damien Neil <dneil@google.com>
Reviewed-by: Joseph Tsai <joetsai@digital-static.net>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
|
|
Change-Id: I5dec35b1432705b3a52859c38e758220282226af
Reviewed-on: https://go-review.googlesource.com/c/go/+/726700
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Sean Liao <sean@liao.dev>
Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
|
|
The linknames have been removed in the latest commits:
isValidNumber, typeFields:
https://github.com/bytedance/sonic/commit/908af5dfaf7d509db1f2c2b1c43f4df728db80a6
unquoteBytes:
https://github.com/bytedance/sonic/commit/8e9090a84be10962046197f1867d297d3e73020a
For #67401
Change-Id: I30b057137932fcf267014ab5470c417298765249
Reviewed-on: https://go-review.googlesource.com/c/go/+/721160
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Joseph Tsai <joetsai@digital-static.net>
Reviewed-by: Junyang Shao <shaojunyang@google.com>
Reviewed-by: Mark Freeman <markfreeman@google.com>
|
|
This change mechanically replaces all occurrences of interface{}
by 'any' (where deemed safe by the 'any' modernizer) throughout
std and cmd, minus their vendor trees.
Since this fix is relatively numerous, it gets its own CL.
Also, 'go generate go/types'.
Change-Id: I14a6b52856c3291c1d27935409bca8d5fd4242a2
Reviewed-on: https://go-review.googlesource.com/c/go/+/719702
Commit-Queue: Alan Donovan <adonovan@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Auto-Submit: Alan Donovan <adonovan@google.com>
|
|
We re-slice the data being processed at the stat of each loop. If the
var that we use to calculate where to re-slice is < 0 or > the length
of the remaining data, return instead of attempting to re-slice.
Change-Id: I1d6c2b6c596feedeea8feeaace370ea73ba02c4c
Reviewed-on: https://go-review.googlesource.com/c/go/+/715260
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Roland Shoemaker <roland@golang.org>
Reviewed-by: Damien Neil <dneil@google.com>
|
|
CL 708495 mass migrated the stdlib to use errors.AsType.
It rewrote the documentation, but uses the non-pointer type
of SemanticError or SyntacticError, which is invalid since
the Error method is declared on the pointer receiver.
Also, call errors.AsType on a separate line for readability.
Change-Id: I2eaf59614e2b58aa4bc8669ab81ce64168c54f13
Reviewed-on: https://go-review.googlesource.com/c/go/+/714660
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com>
Auto-Submit: Joseph Tsai <joetsai@digital-static.net>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
|
|
Previously, we put a jsontext.Encoder (or Decoder)
back into a pool with minimal reset logic.
This was semantically safe since we always did a full reset
after obtaining an Encoder/Decoder back out of the pool.
However, this meant that so long as an Encoder/Decoder was
alive in the pool, any application data referenced by the coder
would be kept alive longer than necessary.
Explicitly, clear such fields so that application data
can be more aggressively garbage collected.
Performance:
name old time/op new time/op delta
Unmarshal/Bool-32 52.0ns ± 3% 50.3ns ± 3% -3.30% (p=0.001 n=10+10)
Marshal/Bool-32 55.4ns ± 3% 54.4ns ± 2% -1.75% (p=0.006 n=10+9)
This only impacts the performance of discrete Marshal/Unmarshal calls.
For the simplest possible call (i.e., to marsha/unmarshal a bool),
there is a 1-2ns slow down. This is an appropriate slowdown
for an improvement in memory utilization.
Change-Id: I5e7d7827473773e53a9dcb3d7fe9052a75481e9f
Reviewed-on: https://go-review.googlesource.com/c/go/+/713640
Reviewed-by: Damien Neil <dneil@google.com>
Reviewed-by: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com>
TryBot-Bypass: Damien Neil <dneil@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
Auto-Submit: Damien Neil <dneil@google.com>
|
|
This is semantically identical and just a cleanup.
Prior to #63397, JSON object names were sorted according to UTF-16
to match the semantic of RFC 8785, but there were a number of
objections in the discussion to using that as the sorting order.
In https://github.com/go-json-experiment/json/pull/121,
we switched to sorting by UTF-8, which matches the behavior
of v1 and avoids an option to toggle the behavior.
However, we should have deleted the stringSlice.Sort method
and just directly called slices.Sort.
From a principled perspective, both UTF-16 and UTF-8 are
reasonable ways to sort JSON object names.
RFC 8259 specifies that the entire JSON text is encoded as UTF-8.
However, the way JSON strings are encoded requires escaping
Unicode codepoints according to UTF-16 surragate halves
(a quirk of JavaScript inherited by JSON).
Thus, JSON is inconsistently both UTF-8 and UTF-16.
Change-Id: Id92b5cc20efe4201827e9d3fccf24ccf894d3e60
Reviewed-on: https://go-review.googlesource.com/c/go/+/713522
Reviewed-by: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
TryBot-Bypass: Damien Neil <dneil@google.com>
Auto-Submit: Damien Neil <dneil@google.com>
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Damien Neil <dneil@google.com>
|
|
When a block is missing the END line trailer, calculate the indexes of
the end and end trailer _before_ continuing the loop, making the
reslicing at the start of the loop work as expected.
Change-Id: If45c8cb473315623618f02cc7609f517a72d232d
Reviewed-on: https://go-review.googlesource.com/c/go/+/714200
Auto-Submit: Roland Shoemaker <roland@golang.org>
Reviewed-by: Damien Neil <dneil@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
|
|
Use "reflect.TypeAssert" can gain some performance improvements:
goos: darwin
goarch: arm64
pkg: encoding/asn1
cpu: Apple M4
│ old │ new │
│ sec/op │ sec/op vs base │
ObjectIdentifierString-10 51.48n ± 1% 49.72n ± 2% -3.41% (p=0.000 n=10)
Marshal-10 7.549µ ± 0% 7.466µ ± 1% -1.10% (p=0.000 n=10)
Unmarshal-10 1.808µ ± 0% 1.798µ ± 0% -0.58% (p=0.000 n=10)
geomean 889.0n 873.8n -1.70%
│ old │ new │
│ B/op │ B/op vs base │
ObjectIdentifierString-10 32.00 ± 0% 32.00 ± 0% ~ (p=1.000 n=10) ¹
Marshal-10 7.336Ki ± 0% 7.336Ki ± 0% ~ (p=1.000 n=10) ¹
Unmarshal-10 432.0 ± 0% 432.0 ± 0% ~ (p=1.000 n=10) ¹
geomean 470.0 470.0 +0.00%
¹ all samples are equal
│ old │ new │
│ allocs/op │ allocs/op vs base │
ObjectIdentifierString-10 1.000 ± 0% 1.000 ± 0% ~ (p=1.000 n=10) ¹
Marshal-10 271.0 ± 0% 271.0 ± 0% ~ (p=1.000 n=10) ¹
Unmarshal-10 24.00 ± 0% 24.00 ± 0% ~ (p=1.000 n=10) ¹
geomean 18.67 18.67 +0.00%
¹ all samples are equal
Updates #62121
Change-Id: I139b9d0c729c36018d4e00216ab6fc8388f3b51b
GitHub-Last-Rev: c87aae53727dd151fadf60f6d0089d7f6a805005
GitHub-Pull-Request: golang/go#75825
Reviewed-on: https://go-review.googlesource.com/c/go/+/710555
Reviewed-by: Roland Shoemaker <roland@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Auto-Submit: Keith Randall <khr@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
|
|
Copying the loop variable is no longer necessary since Go 1.22.
Change-Id: Iebb21dac44a20ec200567f1d786f105a4ee4999d
Reviewed-on: https://go-review.googlesource.com/c/go/+/711640
Reviewed-by: Florian Lehner <lehner.florian86@gmail.com>
Auto-Submit: Damien Neil <dneil@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Damien Neil <dneil@google.com>
Auto-Submit: Tobias Klauser <tobias.klauser@gmail.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
|
|
When the passed byte slice has leading garbage, properly handle ignoring
it and continuing to parse the slice until we find a valid block (or
nothing).
Change-Id: I07e937d9c754fd71b028b99450b48f57b4464457
Reviewed-on: https://go-review.googlesource.com/c/go/+/712140
Reviewed-by: Damien Neil <dneil@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
|
|
The jsontext package represents the location of JSON errors
using a JSON Pointer (RFC 6901). This uses the JSON type system.
Unfortunately the v1 json.UnmarshalTypeError assumes a Go struct-based
mechanism for reporting the location of errors
(and has historically never been implemented correctly since
it was a weird mix of both JSON and Go namespaces; see #43126).
Trying to map a JSON Pointer into UnmarshalTypeError.{Struct,Field}
is difficult to get right without teaching jsontext
about the Go type system.
To reduce the probability of misleading errors,
check whether the last token looks like a JSON array index
and if so, elide the phrase "into Go struct field".
Fixes #74801
Change-Id: Id2088ffb9c339a9238ed38c90223d86a89422842
Reviewed-on: https://go-review.googlesource.com/c/go/+/710676
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Damien Neil <dneil@google.com>
|
|
Originally, DefaultOptionsV1 and DefaultOptionsV2 represented
the full set of all options with specific ones set to true or false.
However, there are certain options such as WithIndent or WithMarshalers
that are neither v1 or v2 specific.
At some point we removed whitespace related options from the set:
https://github.com/go-json-experiment/json/pull/26
This avoids DefaultOptionsV1 or DefaultOptionsV2 from affecting
any previously set whitespace. However, why are whitespace options
special and thus excluded from the set? What about Marshalers?
As a more principaled way to address this, we restrict
DefaultOptionsV1 and DefaultOptionsV2 to only be the options
where the default setting changes between v1 and v2.
All other options are unpopulated.
This avoids a panic with GetOption(DefaultOptionsV2, WithMarshalers)
since DefaultOptionsV2 previously had the presence bit for
Marshalers set to true, but had no actual value.
Now, the presence bit is set to false, so the value is not consulted.
Fixes #75149
Change-Id: I30b45abd35404578b4135cc3bad1a1a2993cb0cf
Reviewed-on: https://go-review.googlesource.com/c/go/+/710878
Reviewed-by: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Damien Neil <dneil@google.com>
|
|
The fully streaming UnmarshalJSONFrom method and UnmarshalFromFunc
introduce an edge case where they can encounter EOF in the stream,
where it should be reported upstream as EOF rather than
ErrUnexpectedEOF or be wrapped within a SemanticError.
This is not possible with other unmarshal methods since the
"json" package would read the appropriate JSON value
before calling the custom method or function.
To avoid custom unmarshal methods from encountering EOF,
check whether the stream is already at EOF for top-level values
before calling the custom method.
Also, when wrapping EOF within a SemanticError, convert it
to ErrUnexpectedEOF to better indicate that this is unexpected.
Fixes #75802
Change-Id: I001396734b7e95b5337f77b71326284974ee730a
Reviewed-on: https://go-review.googlesource.com/c/go/+/710877
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Reviewed-by: Carlos Amedee <carlos@golang.org>
|
|
This change replaces most occurrences (in code as well as in comments) of
errors.As with errors.AsType. It leaves the errors package and vendored
code untouched.
Change-Id: I3bde73f318a0b408bdb8f5a251494af15a13118a
GitHub-Last-Rev: 8aaaa36a5a12d2a6a90c6d51680464e1a3115139
GitHub-Pull-Request: golang/go#75698
Reviewed-on: https://go-review.googlesource.com/c/go/+/708495
Auto-Submit: Michael Pratt <mpratt@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Alan Donovan <adonovan@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
|
|
The legacy parsing of quoted numbers in v1 was according to
the Go grammar for a number, rather than
the JSON grammar for a number.
The former is a superset of the latter.
This is a historical mistake, but usages exist that depend on it.
We already have branches for StringifyWithLegacySemantics
to handle quoted nulls, so we can expand it to handle this.
Fixes #75619
Change-Id: Ic07802539b7cbe0e1f53bd0f7e9bb344a8447203
Reviewed-on: https://go-review.googlesource.com/c/go/+/709615
Reviewed-by: Damien Neil <dneil@google.com>
Auto-Submit: Joseph Tsai <joetsai@digital-static.net>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
|
|
The new version of Go has been optimized, and variables do not need
to be reassigned.
Change-Id: I0374b049271e53510f2b162f6821fb3595f2c8ff
Reviewed-on: https://go-review.googlesource.com/c/go/+/710835
Auto-Submit: Michael Pratt <mpratt@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Alan Donovan <adonovan@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
|
|
Because Decode scanned the input first for the first BEGIN line, and
then the first END line, the complexity of Decode is quadratic. If the
input contained a large number of BEGINs and then a single END right at
the end of the input, we would find the first BEGIN, and then scan the
entire input for the END, and fail to parse the block, so move onto the
next BEGIN, scan the entire input for the END, etc.
Instead, look for the first END in the input, and then the first BEGIN
that precedes the found END. We then process the bytes between the BEGIN
and END, and move onto the bytes after the END for further processing.
This gives us linear complexity.
Fixes CVE-2025-61723
Fixes #75676
Change-Id: I813c4f63e78bca4054226c53e13865c781564ccf
Reviewed-on: https://go-internal-review.googlesource.com/c/go/+/2921
Reviewed-by: Nicholas Husin <husin@google.com>
Reviewed-by: Damien Neil <dneil@google.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/709858
TryBot-Bypass: Michael Pratt <mpratt@google.com>
Auto-Submit: Michael Pratt <mpratt@google.com>
Reviewed-by: Carlos Amedee <carlos@golang.org>
|
|
Within parseSequenceOf, reflect.MakeSlice is being used to pre-allocate
a slice that is needed in order to fully validate the given DER payload.
The size of the slice allocated are also multiple times larger than the
input DER:
- When using asn1.Unmarshal directly, the allocated slice is ~28x
larger.
- When passing in DER using x509.ParseCertificateRequest, the allocated
slice is ~48x larger.
- When passing in DER using ocsp.ParseResponse, the allocated slice is
~137x larger.
As a result, a malicious actor can craft a big empty DER payload,
resulting in an unnecessary large allocation of memories. This can be a
way to cause memory exhaustion.
To prevent this, we now use SliceCapWithSize within internal/saferio to
enforce a memory allocation cap.
Thanks to Jakub Ciolek for reporting this issue.
For #75671
Fixes CVE-2025-58185
Change-Id: Id50e76187eda43f594be75e516b9ca1d2ae6f428
Reviewed-on: https://go-internal-review.googlesource.com/c/go/+/2700
Reviewed-by: Roland Shoemaker <bracewell@google.com>
Reviewed-by: Damien Neil <dneil@google.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/709856
Reviewed-by: Carlos Amedee <carlos@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Michael Pratt <mpratt@google.com>
|
|
The Decoder.InputOffset method was always ambiguous about the exact
offset returned since anything between the end of the previous token
to the start of the next token could be a valid result.
Empirically, it seems that the behavior was to report
the end of the previous token unless Decoder.More is called,
in which case it reports the start of the next token.
This is an odd semantic since a relatively side-effect free method
like More is not quite so side-effect free.
However, our goal is to preserve historical v1 semantic when possible
regardless of whether it made sense.
Note that jsontext.Decoder.InputOffset consistently always reports
the end of the previous token. Users can explicitly choose the
exact position they want by inspecting the UnreadBuffer.
Fixes #75468
Change-Id: I1e946e83c9d29dfc09f2913ff8d6b2b80632f292
Reviewed-on: https://go-review.googlesource.com/c/go/+/703856
Reviewed-by: Damien Neil <dneil@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Junyang Shao <shaojunyang@google.com>
|
|
To make the code more readable and improve performance:
goos: darwin
goarch: arm64
pkg: encoding/xml
cpu: Apple M4
│ old │ new │
│ sec/op │ sec/op vs base │
Marshal-10 1.902µ ± 1% 1.496µ ± 1% -21.37% (p=0.000 n=10)
Unmarshal-10 3.877µ ± 1% 3.418µ ± 2% -11.84% (p=0.000 n=10)
HTMLAutoClose-10 1.314µ ± 3% 1.333µ ± 1% ~ (p=0.270 n=10)
geomean 2.132µ 1.896µ -11.07%
│ old │ new │
│ B/op │ B/op vs base │
Marshal-10 5.570Ki ± 0% 5.570Ki ± 0% ~ (p=1.000 n=10) ¹
Unmarshal-10 7.586Ki ± 0% 7.555Ki ± 0% -0.41% (p=0.000 n=10)
HTMLAutoClose-10 3.496Ki ± 0% 3.496Ki ± 0% ~ (p=1.000 n=10) ¹
geomean 5.286Ki 5.279Ki -0.14%
¹ all samples are equal
│ old │ new │
│ allocs/op │ allocs/op vs base │
Marshal-10 23.00 ± 0% 23.00 ± 0% ~ (p=1.000 n=10) ¹
Unmarshal-10 185.0 ± 0% 184.0 ± 0% -0.54% (p=0.000 n=10)
HTMLAutoClose-10 93.00 ± 0% 93.00 ± 0% ~ (p=1.000 n=10) ¹
geomean 73.42 73.28 -0.18%
¹ all samples are equal
Updates #62121
Change-Id: Ie458e7458d4358c380374571d380ca3b65ca87bb
GitHub-Last-Rev: bb6bb3039328ca1d53ee3d56fd6597109ed76b09
GitHub-Pull-Request: golang/go#75483
Reviewed-on: https://go-review.googlesource.com/c/go/+/704215
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Carlos Amedee <carlos@golang.org>
|
|
Use the correct spelling of the Gregorian calendar.
Change-Id: I7e1d2974d38d5d3ded64f98852ee726c7b84be22
Reviewed-on: https://go-review.googlesource.com/c/go/+/704595
Reviewed-by: Joseph Tsai <joetsai@digital-static.net>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Auto-Submit: Emmanuel Odeke <emmanuel@orijtech.com>
|
|
Use "reflect.TypeAssert" to simplify the code.
There are also some performance gains:
goarch: arm64
pkg: encoding/gob
cpu: Apple M4
│ old │ new │
│ sec/op │ sec/op vs base │
EncodeComplex128Slice-10 1.048µ ± 3% 1.048µ ± 1% ~ (p=0.986 n=10)
EncodeFloat64Slice-10 481.5n ± 0% 538.1n ± 0% +11.75% (p=0.000 n=10)
EncodeInt32Slice-10 560.0n ± 1% 562.2n ± 1% ~ (p=0.239 n=10)
EncodeStringSlice-10 713.1n ± 2% 690.1n ± 1% -3.24% (p=0.000 n=10)
EncodeInterfaceSlice-10 16.10µ ± 3% 16.89µ ± 3% +4.94% (p=0.004 n=10)
DecodeComplex128Slice-10 5.507µ ± 2% 5.488µ ± 2% ~ (p=0.617 n=10)
DecodeFloat64Slice-10 3.359µ ± 1% 3.365µ ± 1% ~ (p=0.403 n=10)
DecodeInt32Slice-10 3.296µ ± 1% 3.290µ ± 2% ~ (p=0.926 n=10)
DecodeStringSlice-10 8.397µ ± 2% 8.459µ ± 1% ~ (p=0.796 n=10)
DecodeStringsSlice-10 18.47µ ± 1% 11.14µ ± 1% -39.69% (p=0.000 n=10)
DecodeBytesSlice-10 5.038µ ± 1% 5.039µ ± 1% ~ (p=0.956 n=10)
DecodeInterfaceSlice-10 40.14µ ± 1% 40.60µ ± 1% +1.16% (p=0.001 n=10)
DecodeMap-10 43.43µ ± 1% 44.09µ ± 1% +1.51% (p=0.000 n=10)
geomean 4.451µ 4.335µ -2.62%
│ old │ new │
│ B/op │ B/op vs base │
EncodeComplex128Slice-10 1.0000 ± ? 0.5000 ± ? ~ (p=0.350 n=10)
EncodeFloat64Slice-10 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=10) ¹
EncodeInt32Slice-10 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=10) ¹
EncodeStringSlice-10 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=10) ¹
EncodeInterfaceSlice-10 19.00 ± 5% 20.00 ± 5% +5.26% (p=0.002 n=10)
DecodeComplex128Slice-10 24.55Ki ± 0% 24.53Ki ± 0% -0.10% (p=0.000 n=10)
DecodeFloat64Slice-10 10.56Ki ± 0% 10.54Ki ± 0% -0.22% (p=0.000 n=10)
DecodeInt32Slice-10 9.539Ki ± 0% 9.516Ki ± 0% -0.25% (p=0.000 n=10)
DecodeStringSlice-10 38.18Ki ± 0% 38.16Ki ± 0% -0.06% (p=0.000 n=10)
DecodeStringsSlice-10 63.96Ki ± 0% 40.51Ki ± 0% -36.65% (p=0.000 n=10)
DecodeBytesSlice-10 22.58Ki ± 0% 22.58Ki ± 0% ~ (p=1.000 n=10)
DecodeInterfaceSlice-10 80.47Ki ± 0% 80.47Ki ± 0% ~ (p=1.000 n=10)
DecodeMap-10 48.81Ki ± 0% 48.81Ki ± 0% ~ (p=1.000 n=10) ¹
geomean ² -8.15% ²
¹ all samples are equal
² summaries must be >0 to compute geomean
│ old │ new │
│ allocs/op │ allocs/op vs base │
EncodeComplex128Slice-10 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=10) ¹
EncodeFloat64Slice-10 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=10) ¹
EncodeInt32Slice-10 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=10) ¹
EncodeStringSlice-10 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=10) ¹
EncodeInterfaceSlice-10 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=10) ¹
DecodeComplex128Slice-10 149.0 ± 0% 148.0 ± 0% -0.67% (p=0.000 n=10)
DecodeFloat64Slice-10 150.0 ± 0% 149.0 ± 0% -0.67% (p=0.000 n=10)
DecodeInt32Slice-10 149.0 ± 0% 148.0 ± 0% -0.67% (p=0.000 n=10)
DecodeStringSlice-10 1.150k ± 0% 1.149k ± 0% -0.09% (p=0.000 n=10)
DecodeStringsSlice-10 2.158k ± 0% 1.158k ± 0% -46.34% (p=0.000 n=10)
DecodeBytesSlice-10 149.0 ± 0% 149.0 ± 0% ~ (p=1.000 n=10) ¹
DecodeInterfaceSlice-10 3.158k ± 0% 3.158k ± 0% ~ (p=1.000 n=10) ¹
DecodeMap-10 160.0 ± 0% 160.0 ± 0% ~ (p=1.000 n=10) ¹
geomean ² -4.83% ²
¹ all samples are equal
² summaries must be >0 to compute geomean
Updates #62121
Change-Id: I1d3534e5001ca185bc8ba5a7ed4ddbc00f85a17e
GitHub-Last-Rev: c0209f8c50e14477069592bfeb161011e7f9e80a
GitHub-Pull-Request: golang/go#75409
Reviewed-on: https://go-review.googlesource.com/c/go/+/702735
Reviewed-by: Mark Freeman <markfreeman@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Michael Pratt <mpratt@google.com>
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Michael Pratt <mpratt@google.com>
|
|
When the json package calls
Marshaler, MarshalerTo, Unmarshaler, or UnmarshalerFrom methods
and a SemanticError is returned, it will automatically
annotate the error with context.
Document this behavior.
Change-Id: Id8e775a7c1c2a6ffc29ea518913591915e8aff87
Reviewed-on: https://go-review.googlesource.com/c/go/+/701956
Reviewed-by: Damien Neil <dneil@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
|
|
Updates #62121
Change-Id: Ic3c4fe84a5dacfd8270aba0d5dd59f83f0a9030f
Reviewed-on: https://go-review.googlesource.com/c/go/+/701955
Reviewed-by: Mark Freeman <markfreeman@google.com>
Reviewed-by: Damien Neil <dneil@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
|
|
Flags struct has field Values but in the comments use Value.
Fix it to correct name Values.
Change-Id: Ib47e62538599a788c69fda27a7e2a97b8cf73263
Reviewed-on: https://go-review.googlesource.com/c/go/+/701415
Reviewed-by: Joseph Tsai <joetsai@digital-static.net>
Reviewed-by: Michael Pratt <mpratt@google.com>
Auto-Submit: Joseph Tsai <joetsai@digital-static.net>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
|
|
This change makes the fast path for ASCII characters inlineable in
DecodeRune and DecodeRuneInString and removes most instances of manual
inlining at call sites.
Here are some benchmark results (no change to allocations):
goos: darwin
goarch: amd64
pkg: unicode/utf8
cpu: Intel(R) Core(TM) i7-6700HQ CPU @ 2.60GHz
│ old │ new │
│ sec/op │ sec/op vs base │
DecodeASCIIRune-8 2.4545n ± 2% 0.6253n ± 2% -74.52% (p=0.000 n=20)
DecodeJapaneseRune-8 3.988n ± 1% 4.023n ± 1% +0.86% (p=0.050 n=20)
DecodeASCIIRuneInString-8 2.4675n ± 1% 0.6264n ± 2% -74.61% (p=0.000 n=20)
DecodeJapaneseRuneInString-8 3.992n ± 1% 4.001n ± 1% ~ (p=0.625 n=20)
geomean 3.134n 1.585n -49.43%
Note: when #61502 gets resolved, DecodeRune and DecodeRuneInString should
be reverted to their idiomatic implementations.
Fixes #31666
Updates #48195
Change-Id: I4be25c4f52417dc28b3a7bd72f1b04018470f39d
GitHub-Last-Rev: 2e352a0045027e059be79cdb60241b5cf35fec71
GitHub-Pull-Request: golang/go#75181
Reviewed-on: https://go-review.googlesource.com/c/go/+/699675
Reviewed-by: Sean Liao <sean@liao.dev>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
|
|
There is no need to explicitly pass in the options
since this contained within the Encoder or Decoder struct
ever since https://github.com/go-json-experiment/json/pull/163.
Thus, remove it as an argument and fetch it from the coder.
This only modifies code that is compiled in under goexperiment.jsonv2.
Change-Id: I6c928b864bf7869889d7ee7d5c1d396fbe71296b
Reviewed-on: https://go-review.googlesource.com/c/go/+/695278
Reviewed-by: Damien Neil <dneil@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
|
|
There is a fast-path optimization for marshaling an any type
that should be semantically identical to when the optimization
is not active (i.e., optimizeCommon is false).
Unfortunately, the optimization accidentally allows NaN,
which this change fixes.
The source of this discrepency is that Encoder.WriteToken(Float(math.NaN()))
emits a JSON string with "NaN", rather than report an error.
The rationale for this behavior is because we needed to decide what to do
with Float(math.NaN()), whether it would return an error, panic, or allow it.
To keep the API simpler (no errors) and less sharp (no panics), we permitted NaN.
The fact that WriteToken allowed it is a logical extension of that decision,
but we could decide to disallow it at least within WriteToken.
As things stand, it is already inconsistent between json/v2 and jsontext, where
json/v2 rejects NaN by default in Marshal, but jsontext allows it in WriteToken.
This only modifies code that is compiled under goexperiment.jsonv2.
Fixes #74797
Change-Id: Ib0708cfbf93c2b059c0a85e4c4544c0604573448
Reviewed-on: https://go-review.googlesource.com/c/go/+/695276
Reviewed-by: Damien Neil <dneil@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
|
|
The type reported in a ErrCycle is the wrong type due to a typo.
This discrepency was detected by setting optimizeCommon to false
and running the tests.
This only modifies code that is compiled in under goexperiment.jsonv2.
Change-Id: I68268f5c719d8b79a67424a35ed0647adf12288c
Reviewed-on: https://go-review.googlesource.com/c/go/+/695277
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Damien Neil <dneil@google.com>
|
|
The Indent function preserves trailing whitespace,
while the v1 emulation under v2 implementation accidentally dropped it.
There was prior logic that attempted to preserve it,
but it did not work correctly since it ran in a defer and
accidentally mutated the dst input argument rather than the output argument.
Move the logic to the end and avoid a defer.
Also, add a test to both v1 and v1in2 to codify this behavior.
This only modifies code that is compiled in under goexperiment.jsonv2.
Updates #13520
Fixes #74806
Change-Id: I22b1a8da5185eb969e2a8a111b625d3752cfcbe8
Reviewed-on: https://go-review.googlesource.com/c/go/+/692195
Reviewed-by: Sean Liao <sean@liao.dev>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: David Chase <drchase@google.com>
Auto-Submit: Sean Liao <sean@liao.dev>
|
|
When EOF is encountered within jsontext.Decoder stream without
starting to parse any token, UnmarshalDecode should report EOF,
rather than converting it into ErrUnexpectedEOF.
This fixes a regression introduced by https://go.dev/cl/689919.
This change only affects code compiled under goexperiment.jsonv2.
Fixes #74835
Change-Id: I7e8e57ab11b462c422c538503ed8c6b91ead53bd
Reviewed-on: https://go-review.googlesource.com/c/go/+/692175
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Sean Liao <sean@liao.dev>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Jake Bailey <jacob.b.bailey@gmail.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Auto-Submit: Joseph Tsai <joetsai@digital-static.net>
|
|
Change-Id: I8631fbc552b85f35b494a8d5a2c0baf68ee66982
Reviewed-on: https://go-review.googlesource.com/c/go/+/690215
Reviewed-by: qiu laidongfeng <2645477756@qq.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Damien Neil <dneil@google.com>
Reviewed-by: Mark Freeman <markfreeman@google.com>
|
|
The jsontext.Decoder.ReadToken method reports a non-EOF error,
if the token stream is truncated and does not form a valid JSON value.
In contrast, the v1 json.Decoder.Token method would report EOF
so long as the input was a prefix of some valid JSON value.
Modify json.Decoder.Token to preserve historical behavior.
This only modifies code that is compiled in under goexperiment.jsonv2.
Updates #69449
Fixes #74750
Change-Id: Ifd281c46f118f0e748076013fefc7659f77c56ed
Reviewed-on: https://go-review.googlesource.com/c/go/+/689516
Reviewed-by: Damien Neil <dneil@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Joseph Tsai <joetsai@digital-static.net>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
|
|
This does the equivalent of CL 681177 for the Encoder.
It preserves the internal buffer between resets.
Change-Id: I5e9353b6d7755e067d4f9a4d1ea3d8f056253027
Reviewed-on: https://go-review.googlesource.com/c/go/+/690375
Reviewed-by: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com>
Auto-Submit: Joseph Tsai <joetsai@digital-static.net>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Damien Neil <dneil@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
|
|
When operating under v1 semantics in the v2 implementation,
a extra data error should take precedence over any semantic error
that could theoretically occur within the value itself.
This change only affects code compiled under goexperiment.jsonv2.
Fixes #74614
Change-Id: I055a606b053fa66b0c766ae205487b8290109285
Reviewed-on: https://go-review.googlesource.com/c/go/+/689919
Reviewed-by: Damien Neil <dneil@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
|
|
There were minor and unnecessary error text changes
when v1 was implemented using v2.
Reduce divergences if possible.
Of the cases reported in #74713, there are no more differences for:
v1: json: cannot unmarshal number into Go value of type chan int
v2: json: cannot unmarshal number into Go value of type chan int
and
v1: json: cannot unmarshal number into Go value of type error
v2: json: cannot unmarshal number into Go value of type error
However, there is a difference between:
v1: json: cannot unmarshal string into Go struct field .F.V of type int
v2: json: cannot unmarshal string into Go struct field S.F.V of type int
For reasons unclear, the v1 logic was always inconsistent about
whether it could properly record the root struct type,
while the v1 emulation layer under v2 is always able to.
This only modifies code that is compiled in under goexperiment.jsonv2.
Fixes #74713
Change-Id: I9e87323b1810130cb929288fdd86aff4be82d5f2
Reviewed-on: https://go-review.googlesource.com/c/go/+/689918
Reviewed-by: Damien Neil <dneil@google.com>
Auto-Submit: Joseph Tsai <joetsai@digital-static.net>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
|
|
The Decoder.Reset method is not preserving the internal buffer between
resets, causing buffer capacity to be lost and resulting in unnecessary
allocations when reusing decoders. This is particularly problematic when
decoding many small messages.
This commit fixes the Reset method to preserve the internal buffer. It
makes sure aliasing is removed if the buffer currently points to an
internal byte slice of a bytes.Buffer. It adds a TestDecoderReset test
structured into subtests to better validate the different scenarios.
Change-Id: Ia685bff47034598224489173bb7f2ffd48e89da5
GitHub-Last-Rev: 462ddc936409ee3da6d75def7d9de59eb3c65f8d
GitHub-Pull-Request: golang/go#74120
Reviewed-on: https://go-review.googlesource.com/c/go/+/681177
Reviewed-by: Sean Liao <sean@liao.dev>
Reviewed-by: Joseph Tsai <joetsai@digital-static.net>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Damien Neil <dneil@google.com>
Auto-Submit: Joseph Tsai <joetsai@digital-static.net>
|
