aboutsummaryrefslogtreecommitdiff
path: root/src/encoding
AgeCommit message (Collapse)Author
17 hoursencoding/json: realign struct encodeState, structFields, and fieldShulhan
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
17 hoursencoding/json: realign struct UnmarshalTypeError and decodeStateShulhan
This reduce the UnmarshalTypeError size from 64 to 56 bytes (-8 bytes), and decodeState from 128 to 96 (-32 bytes).
17 hoursencoding/json: optimize isValidNumber functionShulhan
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
2026-03-30all: fix some minor issues in the commentscuishuang
Change-Id: If6c304efac7a46a9718cdc63ded3d98a26a3a831 Reviewed-on: https://go-review.googlesource.com/c/go/+/760700 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Robert Griesemer <gri@google.com> Reviewed-by: Neal Patel <nealpatel@google.com> Reviewed-by: Fred Sauer <fredsa@google.com> Reviewed-by: Junyang Shao <shaojunyang@google.com> Reviewed-by: Robert Griesemer <gri@google.com>
2026-03-30encoding/hex: speed up DecodeJulien Cretel
This CL eliminates the remaining bounds check for index expressions on Encode's src parameter within the function's loop. Here are some benchmark results (no change to allocations): goos: darwin goarch: arm64 pkg: encoding/hex cpu: Apple M4 │ old │ new │ │ sec/op │ sec/op vs base │ Decode/256-10 166.2n ± 0% 142.9n ± 0% -14.02% (n=180) Decode/1024-10 626.9n ± 0% 532.7n ± 0% -15.03% (n=180) Decode/4096-10 2.472µ ± 0% 2.079µ ± 0% -15.90% (n=180) Decode/16384-10 9.843µ ± 0% 8.266µ ± 0% -16.02% (n=180) geomean 1.262µ 1.069µ -15.25% │ old │ new │ │ B/s │ B/s vs base │ Decode/256-10 1.434Gi ± 0% 1.669Gi ± 0% +16.32% (p=0.000 n=180) Decode/1024-10 1.521Gi ± 0% 1.790Gi ± 0% +17.69% (p=0.000 n=180) Decode/4096-10 1.543Gi ± 0% 1.834Gi ± 0% +18.87% (p=0.000 n=180) Decode/16384-10 1.550Gi ± 0% 1.846Gi ± 0% +19.08% (p=0.000 n=180) geomean 1.512Gi 1.783Gi +17.98% Change-Id: Ibf0471a75087feed528e6b547c7c2c88c6e14d38 GitHub-Last-Rev: dcda1b6a81011649d08db5093f38b12d1ac52f7d GitHub-Pull-Request: golang/go#78436 Reviewed-on: https://go-review.googlesource.com/c/go/+/760781 Auto-Submit: Keith Randall <khr@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Keith Randall <khr@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Keith Randall <khr@golang.org>
2026-03-26encoding/{base32,base64}: speed up EncodeJulien Cretel
This CL clarifies (*Encoding).Encode and speeds it up by reducing the number of bounds checks in its loop. Here are some benchmark results (no change to allocations): goos: darwin goarch: arm64 pkg: encoding/base32 cpu: Apple M4 │ old │ new │ │ sec/op │ sec/op vs base │ EncodeToString-10 7.310µ ± 0% 5.308µ ± 0% -27.39% (n=180) Encode-10 5.651µ ± 0% 3.603µ ± 0% -36.25% (n=180) geomean 6.427µ 4.373µ -31.96% │ old │ new │ │ B/s │ B/s vs base │ EncodeToString-10 1.044Gi ± 0% 1.437Gi ± 0% +37.71% (p=0.000 n=180) Encode-10 1.350Gi ± 0% 2.118Gi ± 0% +56.88% (p=0.000 n=180) geomean 1.187Gi 1.745Gi +46.98% pkg: encoding/base64 │ old │ new │ │ sec/op │ sec/op vs base │ EncodeToString-10 7.058µ ± 0% 6.034µ ± 0% -14.51% (n=180) │ old │ new │ │ B/s │ B/s vs base │ EncodeToString-10 1.081Gi ± 0% 1.264Gi ± 0% +16.97% (p=0.000 n=180) Updates #20206 Change-Id: I7d46891ddb4371df004bfd612a8efc6638715b94 GitHub-Last-Rev: 1caac3d65532fefacbbed57f11a4a49273f173e2 GitHub-Pull-Request: golang/go#78344 Reviewed-on: https://go-review.googlesource.com/c/go/+/759100 Reviewed-by: Keith Randall <khr@golang.org> Auto-Submit: Keith Randall <khr@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Keith Randall <khr@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2026-03-06encoding/json: unwrap IO errors from SyntacticError in transformSyntacticErrorLars Grote
When GOEXPERIMENT=jsonv2 is enabled, transformSyntacticError has a case for bare IO errors (export.IsIOError), but this case is never reached when the IO error is wrapped inside a *jsontext.SyntacticError. This happens because consumeObject wraps errors with wrapWithObjectName before they reach ReadValue, which then wraps them in *SyntacticError via wrapSyntacticError. The result is that transformSyntacticError matches the SyntacticError case first, converts it to a v1 *SyntaxError using only the message string, and discards the underlying IO error chain. This breaks errors.As for callers checking IO errors such as *http.MaxBytesError, which is a common pattern for returning HTTP 413 on oversized request bodies. Fix by checking whether the SyntacticError wraps an IO error and unwrapping it directly, matching v1 behavior which returned IO errors without wrapping. Fixes #77789 Change-Id: Idad84a006a0905b4a20125f676634e1000fb5f48 Reviewed-on: https://go-review.googlesource.com/c/go/+/748860 Reviewed-by: Joseph Tsai <joetsai@digital-static.net> Reviewed-by: Cherry Mui <cherryyz@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: David Chase <drchase@google.com>
2026-02-13encoding/json/v2: allow streaming JSON methods to return errors.ErrUnsupportedJoe Tsai
Allow the MarshalJSONTo and UnmarshalJSONFrom methods to return errors.ErrUnsupported to be skipped in a similar manner to how the caller-specified functions can be skipped as well. Note that the v1 MarshalJSON and UnmarshalJSON methods may not return errors.ErrUnsupported as that would be a breaking change. Also, we couldn't implement it for UnmarshalJSON since that requires consuming the value, which changes the state of the underlying jsontext.Decoder. A side-effect of this change is that MarshalJSONTo and UnmarshalJSONFrom methods may now return sentinel errors. We document that users should avoid calling this methods directly and instead rely on MarshalEncode and UnmarshalDecode, which can handle the ErrUnsupported sentinel error and others that we may add in the future. Fixes #74324 Fixes #76712 Change-Id: I851e907ef8d25e31964148515879a243cb5069c5 Reviewed-on: https://go-review.googlesource.com/c/go/+/744941 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Damien Neil <dneil@google.com> Reviewed-by: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com> Reviewed-by: Junyang Shao <shaojunyang@google.com>
2026-02-13encoding/json/v2: remove SkipFunc sentinel errorJoe Tsai
WARNING: This commit contains breaking changes for those already using GOEXPERIMENT=jsonv2. Existing users of SkipFunc should migrate to errors.ErrUnsupported, for which support was added in at least one prior commit. Updates #74324 Change-Id: Ifbdee39165a134a33ea0005bbc88df0df15f517f Reviewed-on: https://go-review.googlesource.com/c/go/+/745041 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Ethan Lee <ethanalee@google.com> Reviewed-by: Damien Neil <dneil@google.com> Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Nicholas Husin <husin@google.com>
2026-02-13encoding/json/v2: dual support errors.ErrUnsupported and SkipFuncJoe Tsai
This change supports both errors.ErrUnsupported and SkipFunc. In a future change, we will remove SkipFunc entirely in favor of using errors.ErrUnsupported, which exists for a similar pupose. Updates #74324 Change-Id: I5f1ada8e3914513d7d23c504f5965ca8dd95ad18 Reviewed-on: https://go-review.googlesource.com/c/go/+/745040 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Damien Neil <dneil@google.com> Reviewed-by: Junyang Shao <shaojunyang@google.com> Reviewed-by: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com>
2026-02-12encoding/json/v2: remove `unknown` tag option and DiscardUnknownMembersJoe Tsai
WARNING: This commit contains breaking changes for those already using GOEXPERIMENT=jsonv2. This removes support for the `unknown` tag option and the DiscardUnknownMembers marshal option. The `unknown` tag option semantics are a bit too subtle even for experienced Go programmers to understand. Remove support for it. The exact same feature (or something similar) can be added back into a future release of json/v2. We already support the `inline` tag option, which can handle most cases of what someone might want to do with unknown fields (such as preserve them). Fixes #77271 Updates #76444 Change-Id: I875952f0755e58aac4c571869b2cdb56e75cfda9 Reviewed-on: https://go-review.googlesource.com/c/go/+/741320 Reviewed-by: Damien Neil <dneil@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Michael Pratt <mpratt@google.com>
2026-02-02encoding/json: use pooled encoder in Encoder.EncodeJoe Tsai
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>
2026-01-30cmd/go,crypto/mlkem,crypto/x509,encoding/ascii85: clean up ↵Neal Patel
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>
2026-01-23encoding/json: fix typo in package doc.David Symonds
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>
2026-01-22encoding/json: remove unneeded unsafe importkhr@golang.org
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>
2026-01-22encoding/json/v2: remove issue reference in Duration formatting errorJoe Tsai
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>
2025-12-29encoding/gob: clarify docs about pointers to zero values not being sentOleg Zaytsev
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>
2025-12-11encoding/json/jsontext: add symbolic Kind constantsDamien Neil
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>
2025-12-11json/jsontext: normalize all invalid Kinds to 0Damien Neil
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>
2025-12-11encoding/json: report true from v2 Decoder.More when an error is pendingDamien Neil
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>
2025-12-05all: fix some comment issuescuishuang
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>
2025-11-20encoding/json: remove linknamesSean Liao
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>
2025-11-11std,cmd: go fix -any std cmdAlan Donovan
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>
2025-11-04encoding/pem: don't reslice in failure modesRoland Shoemaker
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>
2025-10-24encoding/json/v2: fix typo in documentation about errors.AsTypeJoe Tsai
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>
2025-10-24encoding/json/jsontext: avoid pinning application data in poolsJoe Tsai
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>
2025-10-24encoding/json/v2: use slices.Sort directlyJoe Tsai
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>
2025-10-23encoding/pem: properly calculate end indexesRoland Shoemaker
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>
2025-10-20encoding/asn1: use reflect.TypeAssert to improve performanceapocelipes
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>
2025-10-17all: remove unnecessary loop variable copies in testsTobias Klauser
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>
2025-10-17encoding/pem: properly decode strange PEM dataRoland Shoemaker
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>
2025-10-14encoding/json: avoid misleading errors under goexperiment.jsonv2Joe Tsai
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>
2025-10-13encoding/json/v2: restrict presence of default optionsJoe Tsai
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>
2025-10-13encoding/json/v2: report EOF for top-level values in UnmarshalDecodeJoe Tsai
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>
2025-10-13all: replace calls to errors.As with errors.AsTypeJulien Cretel
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>
2025-10-10encoding/json: fix regression in quoted numbers under goexperiment.jsonv2Joe Tsai
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>
2025-10-10all: omit unnecessary reassignmentcuishuang
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>
2025-10-07encoding/pem: make Decode complexity linearRoland Shoemaker
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>
2025-10-07encoding/asn1: prevent memory exhaustion when parsing using internal/saferioNicholas Husin
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>
2025-10-01encoding/json: fix Decoder.InputOffset regression in goexperiment.jsonv2Joe Tsai
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>
2025-09-29encoding/xml: make use of reflect.TypeAssertapocelipes
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>
2025-09-17encoding/json/v2: fix typo in commentmohanson
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>
2025-09-11encoding/gob: make use of reflect.TypeAssertapocelipes
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>
2025-09-10encoding/json/v2: document context annotation with SemanticErrorJoe Tsai
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>
2025-09-09encoding/json: use reflect.TypeAssertJoe Tsai
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>
2025-09-08encoding/json/internal/jsonflags: fix comment with wrong field nameWeerasak Chongnguluam
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>
2025-09-03unicode/utf8: make DecodeRune{,InString} inlineableJulien Cretel
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>
2025-08-13encoding/json/v2: cleanup error constructorsJoe Tsai
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>
2025-08-13encoding/json/v2: fix incorrect marshaling of NaN in float64 anyJoe Tsai
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>
2025-08-13encoding/json/v2: fix wrong type with cyclic marshal error in map[string]anyJoe Tsai
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>
generated by cgit v1.3 (git 2.53.0) at 2026-04-15 07:26:39 +0000