| Age | Commit message (Collapse) | Author |
|---|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
WARNING: This commit contains breaking changes
for those already using GOEXPERIMENT=jsonv2.
This decomposes FormatBytesWithLegacySemantics as:
* FormatBytesWithLegacySemantics
* FormatByteArrayAsArray
* ParseBytesWithLooseRFC4648
This decomposes FormatTimeWithLegacySemantics as:
* FormatDurationAsNano
* ParseTimeWithLooseRFC3339
In particular, it splits out specific behaviors from the option
that may need to be specified on a finer-grain level.
FormatByteArrayAsArray and FormatDurationAsNano are targeted
to just the default representation of a [N]byte or time.Duration type.
Both of these are not necessary if the `format` tag is explicitly specified.
However, we want to isolate their behavior from other behaviors that used to
be part of FormatBytesWithLegacySemantics and FormatTimeWithLegacySemantics.
ParseBytesWithLooseRFC4648 and ParseTimeWithLooseRFC3339 are targeted
to just historically buggy parsing according to the relevant RFCs,
which may need to be enabled by some services for backwards compatibility.
While FormatTimeWithLegacySemantics is deleted, we still need
FormatBytesWithLegacySemantics to configure highly esoteric
aspects of how v1 used to handle byte slices.
We rename OmitEmptyWithLegacyDefinition as OmitEmptyWithLegacySemantics
to be consistent with other options with the WithLegacySemantics suffix.
Updates #71497
Change-Id: Ic660515fb086fe3af237135f195736de99c2bd33
Reviewed-on: https://go-review.googlesource.com/c/go/+/685395
Auto-Submit: 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: Damien Neil <dneil@google.com>
Reviewed-by: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com>
|
|
This follows up CL 684315 with an expanded section in the v2 doc.
Updates #14750
Updates #71845
Change-Id: I1ffa97e030f5f2b709e8142028e3c8e0e38b80ce
Reviewed-on: https://go-review.googlesource.com/c/go/+/685195
Auto-Submit: Joseph Tsai <joetsai@digital-static.net>
Reviewed-by: Damien Neil <dneil@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
|
|
In the event that the input is just JSON whitespace,
the underlying jsontext.Decoder treats this as an empty stream
and reports io.EOF.
The logic in unmarshalFull simply casted io.EOF as io.ErrUnexpectedEOF,
which is inconsistent with how all other io.ErrUnexpectedEOF are reported,
which are wrapped within a jsontext.SyntacticError.
Do the same thing for consistency.
We add a v1 test (without goexperiment.jsonv2) to verify that
the behavior is identical to how v1 has always behaved.
We add a v1in2 test (with goexperiment.jsonv2) to verify that
the v1in2 behavior correctly replicates historical v1 behavior.
We also fix a faulty check in v1 Decoder.Decode,
where it tried to detect errUnexpectedEnd and
return an unwrapped io.ErrUnexpectedEOF error.
This is the exact semantic that v1 has always done
in streaming Decoder.Decode (but not non-streaming Unmarshal).
There is a prior bug reported in #25956 about this inconsistency,
but we aim to preserve historical v1 behavior to reduce
the probability of churn when v1 is re-implemented in terms of v2.
Fixes #74548
Change-Id: Ibca52c3699ff3c09141e081c85f853781a86ec8e
Reviewed-on: https://go-review.googlesource.com/c/go/+/687115
Auto-Submit: Joseph Tsai <joetsai@digital-static.net>
Reviewed-by: Carlos Amedee <carlos@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Damien Neil <dneil@google.com>
|
|
The jsonopts.Struct.join method unfortunately escapes
the receiver because it is passed to JoinUnknownOption,
which is a dynamically implemented function.
This affects jsontext.Encoder.reset and jsontext.Decoder.reset,
which relied on a local jsonopts.Struct to temporarily store
prior options such that it would have to be heap allocated.
Adjust the signature of JoinUnknownOption to avoid pointers
so that nothing escape.
This is a regression from
https://github.com/go-json-experiment/json/pull/163
Performance:
name old time/op new time/op delta
Marshal/Bool-32 72.1ns ± 2% 51.3ns ± 1% -28.77% (p=0.000 n=10+9)
name old allocs/op new allocs/op delta
Marshal/Bool-32 2.00 ± 0% 1.00 ± 0% -50.00% (p=0.000 n=10+10)
Updates #71845
Change-Id: Ife500d82d3d2beb13652553a4ffdf882c136f5a0
Reviewed-on: https://go-review.googlesource.com/c/go/+/685135
Auto-Submit: Joseph Tsai <joetsai@digital-static.net>
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>
|
|
This follows the precedent set by:
bufio.Writer.AvailableBuffer
bytes.Buffer.AvailableBuffer
both with methods that return a zero-length buffer that
is intended to only be used with a following Write call.
This keeps the older UnusedBuffer method around so that
at least one commit that has both methods for migration purposes.
Updates #71497
Change-Id: I3815f593e09f645280ae5ad9cbdd63a6c147123b
Reviewed-on: https://go-review.googlesource.com/c/go/+/683896
Reviewed-by: Damien Neil <dneil@google.com>
TryBot-Bypass: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
|
|
Based on the discussion in #71631, it is hotly contested
whether the default JSON representation for a Go time.Duration
should be the time.Duration.String format or
a particular profile of ISO 8601.
Regardless of the default, it seems clear that we should
at least support ISO 8601 if specified via a format flag.
Note that this CL does not alter the default representation.
Unfortunately, ISO 8601 is a large and evolving standard
with many optional extensions and optional restrictions.
Thus, the term "ISO 8601 duration" unfortunately does not
resolve to a particular grammar, nor one that is stable.
However, there is precedence that we can follow in this matter.
JSON finds its heritage in JavaScript and
JavaScript is adding a Temporal.Duration type whose default
JSON representation is ISO 8601.
There is a well-specified grammar for their particular
profile of ISO 8601, which is documented at:
https://tc39.es/proposal-temporal/#prod-Duration
This particular CL adds support for ISO 8601 according to
the exact same grammar that JavaScript uses.
While Temporal.Duration is technically still a proposal,
it is already in stage 3 of the TC39 proposal process
(i.e., "no changes to the proposal are expected"
and "has been recommended for implementation")
and therefore close to final adoption.
One major concern with ISO 8601 is that it supports
nominal date units like years, months, weeks, and days
that do not have an accurate meaning without being
anchored to a particular point in time and place on Earth.
Fortunately, JavaScript (by default) avoids producing
Temporal.Duration values with nominal units unless
arithmetic in JavaScript explicitly sets a largestUnits
value that is larger than "hours". In the Go implementation,
we support syntactically parsing the full ISO 8601 grammar
(according to JavaScript), but semantically report an error if
nominal units are present. This ensures that ISO 8601 durations
remain accurate so long as they only use the accurate units
of hours, minutes, or seconds.
Updates #71631
Change-Id: I983593662f2150461ebc486a5acfeb72f0286939
Reviewed-on: https://go-review.googlesource.com/c/go/+/682403
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Damien Neil <dneil@google.com>
Auto-Submit: 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>
|
|
In this blog:
https://blog.trailofbits.com/2025/06/17/unexpected-security-footguns-in-gos-parsers/
the concern was raised that whenever "-" is combined with other options,
the "-" is intepreted as as a name, rather than an ignored field,
which may go contrary to user expectation.
Static analysis demonstrates that there are ~2k instances of `json:"-,omitempty"
in the wild, where almost all of them intended for the field to be ignored.
To prevent this footgun, reject any tags that has "-," as a prefix
and warn the user to choose one of the reasonable alternatives.
The documentation of json/v2 already suggests `json:"'-'"`
as the recommended way to explicitly specify dash as the name.
See Example_fieldNames for example usages of the single-quoted literal.
Update the v1 json documentation to suggest the same thing.
Updates #71497
Change-Id: I7687b6eecdf82a5d894d057c78a4a90af4f5a6e4
Reviewed-on: https://go-review.googlesource.com/c/go/+/683175
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com>
Reviewed-by: Damien Neil <dneil@google.com>
Auto-Submit: Joseph Tsai <joetsai@digital-static.net>
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
|
|
The default representation of a time.Duration is still undecided.
In order to keep the future open, report an error on a time.Duration
without an explicit format flag provided.
Updates #71631
Change-Id: I08248404ff6551723851417c8188a13f53c61937
Reviewed-on: https://go-review.googlesource.com/c/go/+/682455
Auto-Submit: 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>
Reviewed-by: Damien Neil <dneil@google.com>
|
|
Change-Id: I7b2c391749e0113e006f37b2ac1ebfe3ee0a4e0e
Reviewed-on: https://go-review.googlesource.com/c/go/+/680715
TryBot-Bypass: Damien Neil <dneil@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Joseph Tsai <joetsai@digital-static.net>
Auto-Submit: Damien Neil <dneil@google.com>
|
|
This imports the proposed new v2 JSON API implemented in
github.com/go-json-experiment/json as of commit
d3c622f1b874954c355e60c8e6b6baa5f60d2fed.
When GOEXPERIMENT=jsonv2 is set, the encoding/json/v2 and
encoding/jsontext packages are visible, the encoding/json
package is implemented in terms of encoding/json/v2, and
the encoding/json package include various additional APIs.
(See #71497 for details.)
When GOEXPERIMENT=jsonv2 is not set, the new API is not
present and the encoding/json package is unchanged.
The experimental API is not bound by the Go compatibility
promise and is expected to evolve as updates are made to
the json/v2 proposal.
The contents of encoding/json/internal/jsontest/testdata
are compressed with zstd v1.5.7 with the -19 option.
Fixes #71845
For #71497
Change-Id: Ib8c94e5f0586b6aaa22833190b41cf6ef59f4f01
Reviewed-on: https://go-review.googlesource.com/c/go/+/665796
Auto-Submit: 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>
Reviewed-by: Joseph Tsai <joetsai@digital-static.net>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
|
