Update #5000
Should reduce the flakiness a little. Malloc counting is important
to general testing but not to the build dashboard, which uses -short.
R=golang-dev, dsymonds
CC=golang-dev
https://golang.org/cl/12866047
Remove custom support for time.Time.
No new tests: the tests for the time.Time special case
now test the general case.
R=golang-dev, bradfitz
CC=golang-dev
https://golang.org/cl/12751045
See golang.org/s/go12xml for design.
Repeat of CL 12603044, which was submitted accidentally
and then rolled back.
Fixes#2771.
Fixes#4169.
Fixes#5975.
Fixes#6125.
R=golang-dev
CC=golang-dev
https://golang.org/cl/12919043
fat fingers - did not intend to submit.
depends on the Unmarshaler CL anyway.
««« original CL description
encoding/xml: add, support Marshaler interface
See golang.org/s/go12xml for design.
Fixes#2771.
Fixes#4169.
Fixes#5975.
Fixes#6125.
R=golang-dev, iant, dan.kortschak
CC=golang-dev
https://golang.org/cl/12603044
»»»
TBR=golang-dev
CC=golang-dev
https://golang.org/cl/12918043
Again, it still allocates but the code is simple.
benchmark old ns/op new ns/op delta
BenchmarkReadSlice1000Int32s 35580 11465 -67.78%
benchmark old MB/s new MB/s speedup
BenchmarkReadSlice1000Int32s 112.42 348.86 3.10x
R=golang-dev, bradfitz
CC=golang-dev
https://golang.org/cl/12694048
There are a few different places in the code that escape
possibly-problematic characters like < > and &.
This one was the only one missing &, so add it.
This means that if you Marshal a string, you get the
same answer you do if you Marshal a string and
pass it through the compactor. (Ironically, the
compaction makes the string longer.)
Because html/template invokes json.Marshal to
prepare escaped strings for JavaScript, this changes
the form of some of the escaped strings, but not
their meaning.
R=golang-dev, bradfitz
CC=golang-dev
https://golang.org/cl/12708044
The old code was caching per-type struct field info. Instead,
cache type-specific encoding funcs, tailored for that
particular type to avoid unnecessary reflection at runtime.
Once the machine is built once, future encodings of that type
just run the func.
benchmark old ns/op new ns/op delta
BenchmarkCodeEncoder 48424939 36975320 -23.64%
benchmark old MB/s new MB/s speedup
BenchmarkCodeEncoder 40.07 52.48 1.31x
Additionally, the numbers seem stable now at ~52 MB/s, whereas
the numbers for the old code were all over the place: 11 MB/s,
40 MB/s, 13 MB/s, 39 MB/s, etc. In the benchmark above I compared
against the best I saw the old code do.
R=rsc, adg
CC=gobot, golang-dev, r
https://golang.org/cl/9129044
Simple approach. Still generates garbage, but not as much.
benchmark old ns/op new ns/op delta
BenchmarkWriteSlice1000Int32s 40260 18791 -53.33%
benchmark old MB/s new MB/s speedup
BenchmarkWriteSlice1000Int32s 99.35 212.87 2.14x
Fixes#2634.
R=golang-dev, crawshaw
CC=golang-dev
https://golang.org/cl/12680046
Original CL by rsc (11916045):
The motivation for disallowing them was RFC 4180 saying
"The last field in the record must not be followed by a comma."
I believe this is an admonition to CSV generators, not readers.
When reading, anything followed by a comma is not the last field.
Fixes#5892.
R=golang-dev, rsc, r
CC=golang-dev
https://golang.org/cl/12294043
EscapeText now escapes 0xFFFD returned from DecodeRune as 0xFFFD, rather than passing through the original byte.
Fixes#5880.
R=golang-dev, r, bradfitz, adg
CC=golang-dev
https://golang.org/cl/11975043
Phrases like "returns whether or not the image is opaque" could be
describing what the function does (it always returns, regardless of
the opacity) or what it returns (a boolean indicating the opacity).
Even when the "or not" is missing, the phrasing is bizarre.
Go with "reports whether", which is still clunky but at least makes
it clear we're talking about the return value.
These were edited by hand. A few were cleaned up in other ways.
R=golang-dev, dsymonds
CC=golang-dev
https://golang.org/cl/11699043
I want to think more carefully about this.
We put this in because Marshal encoded named []byte but Unmarshal rejected them.
And we noticed that Marshal's behavior was undocumented so we documented it.
But I am starting to think the docs and Unmarshal were correct and Marshal's
behavior was the problem.
Rolling back to give us more time to think.
««« original CL description
json: unmarshal types that are byte slices.
The json package cheerfully would marshal
type S struct {
IP net.IP
}
but would give an error when unmarshalling. This change allows any
type whose concrete type is a byte slice to be unmarshalled from a
string.
Fixes#5086.
R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/11161044
»»»
R=golang-dev, r
CC=golang-dev
https://golang.org/cl/11042046
In practice, rejecting an entire structure due to a single invalid byte
in a string is just too picky, and too hard to track down.
Be consistent with the bulk of the standard library by converting
invalid UTF-8 into UTF-8 with replacement runes.
R=golang-dev, crawshaw
CC=golang-dev
https://golang.org/cl/11211045
The json package cheerfully would marshal
type S struct {
IP net.IP
}
but would give an error when unmarshalling. This change allows any
type whose concrete type is a byte slice to be unmarshalled from a
string.
Fixes#5086.
R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/11161044
The first identifier in an Object Identifer must be between 0 and 2
inclusive. The range of values that the second one can take depends
on the value of the first one.
The two first identifiers are not necessarily encoded in a single octet,
but in a varint.
R=golang-dev, agl
CC=golang-dev
https://golang.org/cl/10140046
According to X.690, only 0 and 255 are allowed as values
for encoded booleans. Also added some test for parsing
booleans
R=golang-dev, agl, r
CC=golang-dev
https://golang.org/cl/9692043
The *Encoder is almost always garbage. It doesn't need an
encodeState inside of it (and its bytes.Buffer), since it's
only needed locally inside of Encode.
benchmark old ns/op new ns/op delta
BenchmarkEncoderEncode 2562 2553 -0.35%
benchmark old bytes new bytes delta
BenchmarkEncoderEncode 283 102 -63.96%
R=r
CC=gobot, golang-dev
https://golang.org/cl/9365044
If there are no tags, the rules are the same as before.
If there is a tagged field, choose it if there is exactly one
at the top level of all fields.
More tests. The old tests were clearly inadequate, since
they all pass as is. The new tests only work with the new code.
R=golang-dev, iant
CC=golang-dev
https://golang.org/cl/8617044
The old code was incorrect and also broken. It passed the tests by accident.
The new algorithm is:
1) Sort the fields in order of names.
2) For all fields with the same name, sort in increasing depth.
3) Choose the single field with shortest depth.
If any of the fields of a given name has a tag, do the above using
tagged fields of that name only.
Fixes#5245.
R=iant
CC=golang-dev
https://golang.org/cl/8583044
If a fixed size array is passed in as the decode target and the JSON
to decode has extra array elements that are objects, then previously
the decoder would return a "data changing underfoot" error.
Fixes#3717.
R=golang-dev, adg, rsc
CC=golang-dev
https://golang.org/cl/7490046
If two fields have the same name but different explicit name spaces,
treat as non-conflicting. This allows parsing common XML formats
that have ns1:tag and ns2:tag in the same XML element.
Fixes#4691.
Allow setting the default name space for unadorned tags, by
writing to Decoder.DefaultSpace. This allows turned the job of
parsing common XML formats that have tag and ns2:tag in the
same XML element into the first case by setting DefaultSpace="ns1".
Fixes#3703.
Use name space attributes when decoding.
Attach name space to attributes when encoding.
Could be done with fewer annotations, but semantically correct as is.
Fixes#3526.
R=golang-dev, bradfitz
CC=golang-dev
https://golang.org/cl/7227056
Adds a new reader to filter newlines, which fixes errors seen in the
decoder chunking code. Found additional issues with whitespace handling
after the first padding character.
Fixes#4779.
R=minux.ma, rsc, bradfitz
CC=golang-dev
https://golang.org/cl/7311069
The old code just assumed that the only thing
you can embed is a struct. Not true.
Fixes#3803.
R=golang-dev, adg
CC=golang-dev
https://golang.org/cl/7743043
Edit encoding/base64's internals and tests to match encoding/base32.
Properly handling line breaks in padding is left for another CL.
R=dsymonds
CC=golang-dev
https://golang.org/cl/7693044
Right now it says 'invalid type S' for a struct type S.
Instead, say which type inside the struct is the problem.
Fixes#4825.
R=golang-dev, iant
CC=golang-dev
https://golang.org/cl/7301102
The second attempt at the Unmarshal optimization allowed
panics to get out of the json package. Add test for that bug
and remove the optimization.
Let's stop trying to optimize Unmarshal.
Fixes#4784.
R=golang-dev, bradfitz
CC=golang-dev
https://golang.org/cl/7300108
This CL also replaces similar loops in other stdlib
package tests with calls to AllocsPerRun.
Fixes#4461.
R=minux.ma, rsc
CC=golang-dev
https://golang.org/cl/7002055
The JSON unmarshaller failed to allocate an array when there
are no values for the input causing the `[]` unmarshalled
to []interface{} to generate []interface{}(nil) rather than
[]interface{}{}. This wasn't caught in the tests because Decode()
works correctly and because jsonBig never generated zero-sized
arrays. The modification to scanner_test.go quickly triggers
the error:
without the change to decoder.go, but with the change to scanner_test.go:
$ go test
--- FAIL: TestUnmarshalMarshal (0.10 seconds)
decode_test.go:446: Marshal jsonBig
scanner_test.go:206: diverge at 70: «03c1OL6$":null},{"[=» vs «03c1OL6$":[]},{"[=^\»
FAIL
exit status 1
FAIL encoding/json 0.266s
Also added a simple regression to decode_test.go.
R=adg, dave, rsc
CC=golang-dev
https://golang.org/cl/7196050
Roll back CL making primitive type unmarshal faster,
because it broke the Unmarshal of malformed data.
Add benchmarks for unmarshal of primitive types.
Update #3949.
R=golang-dev, bradfitz
CC=golang-dev
https://golang.org/cl/7228061
Otherwise it's impossible to know how much data from the
json.Decoder's underlying Reader was actually consumed.
The old fix from golang.org/issue/1955 just added docs. This
provides an actual mechanism.
Update #1955
R=golang-dev, adg, rsc
CC=golang-dev
https://golang.org/cl/7181053
Go 1.0 behavior was to create an UnmarshalFieldError when a json value name matched an unexported field name. This error will no longer be created and the field will be skipped instead.
Fixes#4660.
R=adg, rsc, bradfitz
CC=golang-dev
https://golang.org/cl/7139049
bytes.Equal is simpler to read and should also be faster because
of short-circuiting and assembly implementations.
Change generated automatically using:
gofmt -r 'bytes.Compare(a, b) == 0 -> bytes.Equal(a, b)'
gofmt -r 'bytes.Compare(a, b) != 0 -> !bytes.Equal(a, b)'
R=golang-dev, dave, adg, rsc
CC=golang-dev
https://golang.org/cl/7038051
Add a check for this case and don't try to follow the anonymous
type's non-existent fields.
Fixes#4474.
R=rsc
CC=golang-dev
https://golang.org/cl/6945065
Allows encoding and decoding of maps with key of string kind, not just string type.
Fixes#3519.
R=rsc, dave
CC=golang-dev
https://golang.org/cl/6943047
Fixes#3559.
This makes Marshal handle fields marked ",any" instead of ignoring
them. That makes Marshal more symmetrical with Unmarshal, which seems
to have been a design goal.
Note some test cases were changed, because this patch changes
marshalling behavior. I think the previous behavior was buggy, but
there's still a backward-compatibility question to consider.
R=rsc
CC=golang-dev, n13m3y3r
https://golang.org/cl/6938068
reader.Read() can return both 0,nil and len(buf),err.
To be safe, we use io.ReadFull instead of doing reader.Read directly.
Fixes#3472.
R=bradfitz, rsc, ality
CC=golang-dev
https://golang.org/cl/6285050
As discussed in issue 2540, nulls are allowed for any type in JSON so they should not result in an error during Unmarshal.
Fixes#2540.
R=rsc
CC=golang-dev
https://golang.org/cl/6759043
