reflect: gccgo and go differ on handling of fields from embedded structs #11007
Labels
Milestone
Comments
|
yeah, gc and gccgo implemented different rules regarding
embedded structs.
gc seems to think all embedded structs are settable.
gccgo thinks all embedded structs are unsettable.
|
|
Seems to me that a mix between the two is the right option, matching the language. // package example
type unexported struct {
Exported string
}
type Exported struct {
unexported
}
// package main
import "example"
func main() {
val := &example.Exported{}
val.Exported = "test" // Ok
reflect.ValueOf(val).Elem().FieldByName("Exported").SetString("Hello world") // Also ok
val.unexported = /*something*/ // invalid
reflect.ValueOf(val).Elem().Field(0).Set(/*something*/) // Also invalid
} |
|
Looks like #7363 . |
|
Oh, I see that you saw that. Hmmm. This does seem to be an issue in the reflect package. It doesn't currently consider how an embedded field affects visibility. |
|
The fix for #7363 should address this too. |
|
CL https://golang.org/cl/14010 mentions this issue. |
|
CL https://golang.org/cl/14085 mentions this issue. |
mpvl
added a commit
that referenced
this issue
Oct 26, 2015
This CL changes reflect to allow access to exported fields and methods in unexported embedded structs for gccgo and after gc has been adjusted to disallow access to embedded unexported structs. Adresses #12367, #7363, #11007, and #7247. Change-Id: If80536eab35abcd25300d8ddc2d27d5c42d7e78e Reviewed-on: https://go-review.googlesource.com/14010 Reviewed-by: Russ Cox <rsc@golang.org>
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Test case: http://play.golang.org/p/pqIQCAJOXp
On go 1.4.2 and tip that works fine (as seen on the playground) but on gccgo
go version go1.4.2 gccgo (Ubuntu 5.1~rc1-0ubuntu1) 5.0.1 20150414 (prerelease) [gcc-5-branch revision 222102] linux/amd64it will fail with
This might be related to #7363 however I assumed that Exported fields from embedded structs should have the same visibility as if it was on the parent struct.
The text was updated successfully, but these errors were encountered: