reflect: PtrTo of struct with embedded field does not implement interfaces correctly

[bryanturley]

This one is hard to explain, luckily it is very simply reproduced.
Keep your attention on output regarding the anonymous struct F {} inside of struct Z {}

If you uncomment the /* */ area at the end.  The reflection answers before it change.
I would say they are only correct when that section is uncommented.
This program should never print "... == false".

http://play.golang.org/p/GDUfhs8g2H

Discovered originally using go1.3 linux amd64.

[ianlancetaylor]

Comment 1:

Labels changed: added repo-main, release-go1.4.

Status changed to Accepted.

[bryanturley]

Comment 2:

It is not just PtrTo() it also fails on line 99 with value.Addr().
Line 92 and 99 try to do the same thing different ways and both fail only on Z.F 
if you uncomment lines 103-109  they both start working properly. If you add something
after the array in F it also works, which is what G is.
F is exactly the same layout as C which never fails.
I would guess it is a compiler bug in the generated type tables.
That is a guess though.

[ianlancetaylor]

Comment 3:

Addr calls PtrTo to get the type of the value that it returns.  I'm pretty sure that
PtrTo is where the problem lies.
When you uncomment your lines, the compiler generates the type tables, and the reflect
package uses them.  When the lines are commented out, the compiler does not generate the
type tables (because the compiler never sees anything take the address of a value of
that type) and the reflect package creates the type tables.  So, I'm pretty sure that
the problem is in the reflect package, and the compiler is fine.

[bryanturley]

Comment 4:

You know better than me, I can only guess at the moment.
I assumed the compiler always generated the full type tables because of potential
reflection, but I haven't been any where near that code.
Took me a while to even think it was a go bug when I was locating it.
Sorry the reproducer has so much fluff.

[rsc]

Comment 5:

Definitely a bug, definitely what Ian says in #3, but not going to be able to fix for Go
1.4.

Labels changed: added release-go1.5, removed release-go1.4.

[bryanturley]

Comment 6:

It is easy enough to workaround for now.