-
Notifications
You must be signed in to change notification settings - Fork 18k
cmd/compile: empty PkgPath for embedded, unexported struct field #7247
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
Comments
This was fixed in https://code.google.com/p/go/source/detail?r=6c0339d94123. |
For the record, this prints an empty PkgPath: http://play.golang.org/p/5YqvyuKXDb |
Rolled back. See issue #7522. Not touching this for Go 1.4 Labels changed: added release-go1.5, removed release-go1.4. |
I presume #12367 will address this too so maybe this can be closed now? |
CL https://golang.org/cl/14010 mentions this issue. |
@mwhudson yes, it will address it. CL 14010 14085 mention this Issue and it will be automatically closed as soon as 14085 is checked in. The bulk of the issues will go once 14010-2 are checked in. CL 14085 will lock down gc. We need to wait a bit for that to allow package writers to fix their handling of embedded unexported structs. |
CL https://golang.org/cl/14085 mentions this issue. |
Any update on this, in particular when the fix for gccgo might get merged? |
@laboger: I'm waiting on Russ' review. As soon as 14010 and the accompanying changes for JSON and XML are checked in, it will be fixed. The fix for gc will come in after everybody has had a chance to adopt their On Thu, Oct 1, 2015 at 4:38 PM, laboger notifications@github.com wrote:
|
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>
The "fixes" for gccgo have gone in. Or more precisely, the reflect library is now loosened up and xml and json are adjusted to make use of the new semantics. After the dust is settled, gc will be locked up in the same way as gccgo, after which the two should be fully compatible. Please let me know if you have any problems with gccgo. |
The text was updated successfully, but these errors were encountered: