-
Notifications
You must be signed in to change notification settings - Fork 17.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
reflect: wrong struct field names for embedded byte, rune #17766
Labels
Milestone
Comments
This is a bug in the way the gc compiler chooses field names, not a bug in reflect.
|
cc: @griesemer |
CL https://golang.org/cl/35732 mentions this issue. |
CL https://golang.org/cl/35731 mentions this issue. |
gopherbot
pushed a commit
that referenced
this issue
Jan 25, 2017
…uctField docs The runtime internal structField interprets name=="" as meaning anonymous, but the exported reflect.StructField has always set Name, even for anonymous fields, and also set Anonymous=true. The initial implementation of StructOf confused the internal and public meanings of the StructField, expecting the runtime representation of anonymous fields instead of the exported reflect API representation. It also did not document this fact, so that users had no way to know how to create an anonymous field. This CL changes StructOf to use the previously documented interpretation of reflect.StructField instead of an undocumented one. The implementation of StructOf also, in some cases, allowed creating structs with unexported fields (if you knew how to ask) but set the PkgPath incorrectly on those fields. Rather than try to fix that, this CL changes StructOf to reject attempts to create unexported fields. (I think that may be the right design choice, not just a temporary limitation. In any event, it's not the topic for today's work.) For #17766. Fixes #18780. Change-Id: I585a4e324dc5a90551f49d21ae04d2de9ea04b6c Reviewed-on: https://go-review.googlesource.com/35731 Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Inspired by discussion on #17746, https://play.golang.org/p/X3OBse1q8_
Prints:
The second print should be fixed. It's always been this way, though, so it can and should wait until Go 1.9.
/cc @mdempsky @griesemer @alandonovan @mpvl
The text was updated successfully, but these errors were encountered: