encoding/json: json.Unmarshal on embedded unexported structs panics #24152
Comments
dsnet
added
the
NeedsInvestigation
|
I got it to work, the inner nesting of your struct "otherType" needs to be public -> "OtherType". But i don't know if this is intended behavior. |
|
when it panic with a string, the conversion from string to error interface in |
|
@Ogditsira I know that you can export the type, but the point was previously you didn't have to do it and I'm very sure that this panic is not intended behavior. As noted, in 1.9 it worked flawlessly. |
|
This is related to #22546. |
|
This is a regression from 1.9 and should be fixed for 1.11. It's possible that it will even be included in the 1.10.1 point release (whenever that is). |
|
The underlying regression is #24153. |
dsnet
added
NeedsFix
|
Change https://golang.org/cl/97796 mentions this issue: |
|
Re-opening for consideration into cherry-picking for Go1.10.1. |
bcmills
added
NeedsDecision
spf13
added
the
NeedsFix
gopherbot
removed
the
NeedsDecision
|
CL 97796 OK for Go 1.10.1 |
andybons
added
CherryPickApproved
|
Change https://golang.org/cl/102784 mentions this issue: |
…e reflect.Value.Addr().Elem()
Consider the following:
type child struct{ Field string }
type parent struct{ child }
p := new(parent)
v := reflect.ValueOf(p).Elem().Field(0)
v.Field(0).SetString("hello") // v.Field = "hello"
v = v.Addr().Elem() // v = *(&v)
v.Field(0).SetString("goodbye") // v.Field = "goodbye"
It would appear that v.Addr().Elem() should have the same value, and
that it would be safe to set "goodbye".
However, after CL 66331, any interspersed calls between Field calls
causes the RO flag to be set.
Thus, setting to "goodbye" actually causes a panic.
That CL affects decodeState.indirect which assumes that back-to-back
Value.Addr().Elem() is side-effect free. We fix that logic to keep
track of the Addr() and Elem() calls and set v back to the original
after a full round-trip has occured.
Fixes #24152
Updates #24153
Change-Id: Ie50f8fe963f00cef8515d89d1d5cbc43b76d9f9c
Reviewed-on: https://go-review.googlesource.com/97796
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-on: https://go-review.googlesource.com/102784
Run-TryBot: Andrew Bonventre <andybons@golang.org>
Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Please answer these questions before submitting your issue. Thanks!
What version of Go are you using (
go version)?go version go1.10 linux/amd64
go version go1.10 windows/amd64
Does this issue reproduce with the latest release?
yes. Does not happen with go1.9
What operating system and processor architecture are you using (
go env)?Windows 10 amd64
Ubuntu Xenial amd64 16.04.2 LTS
What did you do?
https://play.golang.org/p/ZDEBiSJKERw
What did you expect to see?
The release notes state:
These fields however aren't pointers and it panics instead of just returning an error
What did you see instead?
The text was updated successfully, but these errors were encountered: