Thanks for the issue. This looks like two anonymous types (declared in two separate packages, but identical) are being given different type pointers.

Here's a cleaner repro:

a.go:

package main

import "b"

func main() {
	_ = b.GetY().(struct{ x, y int })

b/b.go:

package b

func GetY() interface{} {
	return struct{ x, y int }{2, 3}
}

GetY gets inlined, so the type test boils down to (in main.main):

 104c52f:       48 8d 05 8a e5 00 00    lea    0xe58a(%rip),%rax        # 105aac0 <runtime.rodata+0xe500>
 104c536:       48 8d 0d 03 e6 00 00    lea    0xe603(%rip),%rcx        # 105ab40 <runtime.rodata+0xe580>
 104c53d:       48 39 c8                cmp    %rcx,%rax
 104c540:       75 0a                   jne    104c54c <main.main+0x4c>

Which seems wrong. Both of those LEAs should be of the same address.
I thought we had fixed all the non-unique type problems. Guess not.

I'll look more in the morning.

@crawshaw @rsc

These are different types.

The fields x and y are unexported, and so cannot be accessed outside of package b. If you export them, X and Y, this code works as you would expect.

@crawshaw

even if so, i think the error should be more clear, because the folowing is unreadable:

panic: interface conversion: interface {} is struct { x int; y int }, not struct { x int; y int }
                                                 ^------------- same thing ---------^

probably it should be
panic: interface conversion: interface {} is b. struct { x int; y int }, not main. struct { x int; y int }

A better error would be better.

Hm, so is the bug in 1.7 then? It ran the repro successfully.

I would say so, yes. Probably something I introduced when working on binary size reductions for 1.7. I elided some unnecessary pkgpath values, and seem to remember at least once getting overenthusiastic.

Repro runs successfully for all of 1.2 through 1.7...

Oh. Hmm.

It still fits my mental model that these are separate types, and you shouldn't be able to reach the unexported fields of another package's type, even if it's unnamed.

@ianlancetaylor, @griesemer, opinions?

Spec seems pretty clear that 1.8 is right and 1.2-1.7 are wrong. As part of type identity:

Lower-case field names from different packages are always different.

It looks to me like Go 1.8 is correct and earlier versions of Go were not. My guess is that Robert's new export data fixed the bug.

(I also agree that a clearer error would be nice.)

This is clearly correct in Go 1.8. There were several subtle bugs in the old export data (though I don't know for sure what fixed this. I'll assign it to me for a better error message.

Leaving for 1.10 for improved error message (should probably mentioned declaration positions). Clearly not urgent as it's a rare case.

Related: #17283 and #21282.

Change https://golang.org/cl/116255 mentions this issue: runtime: slightly better error message for assertion panics with identical looking types

Change https://golang.org/cl/123395 mentions this issue: runtime: don't say "different packages" if they may not be different