Originally it was an error, which made perfect sense, but in issue 2540
I got talked out of this sensible behavior. I'm not thrilled with the "new"
behavior but it's been there since Go 1.1 so we're stuck with it now.
Fixes#6724.
LGTM=bradfitz
R=golang-codereviews, bradfitz
CC=golang-codereviews
https://golang.org/cl/100430043
Don't make copies of keys while decoding, and don't use the
expensive strings.EqualFold when it's not necessary. Instead,
note in the existing field cache what algorithm to use to
check fold equality... most keys are just ASCII letters.
benchmark old ns/op new ns/op delta
BenchmarkCodeDecoder 137074314 103974418 -24.15%
benchmark old MB/s new MB/s speedup
BenchmarkCodeDecoder 14.16 18.66 1.32x
Update #6496
R=golang-dev, rsc, adg, r, mikioh.mikioh
CC=golang-dev
https://golang.org/cl/13894045
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
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
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
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
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
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
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
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
Number represents the actual JSON text,
preserving the precision and
formatting of the original input.
R=rsc, iant
CC=golang-dev
https://golang.org/cl/6202068
Removes an incorrect code comment and some superfluous variables.
The comment I removed says that struct fields which implement
Unmarshaler must be pointers, even if they're in an addressable
struct. That's not the case, and there's already a test in decode_test.go
that demonstrates as much.
Encoding/json has quite a few assignments of reflect.Values to extra
variables – things like "iv := v" when there's no need to make a copy. I
think these are left over from a previous version of the reflect API. If they
aren't wanted, I wouldn't mind going through the package and getting
rid of the rest of them.
R=rsc
CC=golang-dev
https://golang.org/cl/6318047
We should, after Go 1, make them work the same as
package xml, that is, make them appear in the outer
struct. For now turn them off so that people do not
depend on the old behavior.
Fixing them is issue 3069.
R=golang-dev, bradfitz
CC=golang-dev
https://golang.org/cl/5656102
An old update for API changes in reflect package left several
helper variables that do not have a meaning anymore, and
the type checking of arrays vs slices was broken.
Fixes#2513.
R=ultrotter, rsc
CC=golang-dev, remy
https://golang.org/cl/5488094
All but 3 cases (in gcimporter.go and hixie.go)
are automatic conversions using gofix.
No attempt is made to use the new Append functions
even though there are definitely opportunities.
R=golang-dev, gri
CC=golang-dev
https://golang.org/cl/5447069
This is Go 1 package renaming CL #1.
This one merely moves the source; the import strings will be
changed after the next weekly release.
The only edits are in Makefiles.
R=r, rsc
CC=golang-dev
https://golang.org/cl/5331060
