Test case has three input files.

a.go:

package a

import "reflect"

type S struct {
	x int
}

func F() string {
	v := reflect.TypeOf(S{0})
	return v.PkgPath()
}

b.go:

package b

import "reflect"

type X int

func F1() string {
	type x X

	s := struct {
		*x
	}{nil}
	v := reflect.TypeOf(s)
	return v.Field(0).PkgPath
}

func F2() string {
	type y X

	s := struct {
		*y
	}{nil}
	v := reflect.TypeOf(s)
	return v.Field(0).PkgPath
}

main.go:

package main

import (
	"fmt"
	"os"

	"./a"
	"./b"
)

func main() {
	ok := true
	if s, want := a.F(), "a"; s != want {
		fmt.Printf("a.F() == %q, expected %q\n", s, want)
		ok = false
	}
	if s, want := b.F1(), ""; s != want {
		fmt.Printf("b.F1() == %q, expected %q\n", s, want)
		ok = false
	}
	if s, want := b.F2(), ""; s != want {
		fmt.Printf("b.F2() == %q, expected %q\n", s, want)
		ok = false
	}
	if !ok {
		os.Exit(1)
	}
}

The two functions in b.go are identical except for the name they use for the type defined within the function. Therefore, they should return the same value. All Go releases since Go 1 have returned the empty string for the PkgPath of a struct field of embedded pointer type, even if the embedded pointer type is not exported. That seems wrong, but it is what we have done, and it is what the code in main.go expects.

However, in this case, F1 does not return an empty string. The reason is that F1 uses a name x that is internally represented as a string with the exported flag (the least significant bit of the first byte in the reflect.name) clear. That is fine, but in a.go the existence of the field x in S produces a name x that is internally represented as a string with the exported flag set. Although those two reflect.name values are different, the compiler generates the same symbol name for both (type..namedata.x.). The linker merges the two names, causing F1 to unexpectedly see an unexported name, and to therefore return an unexpected non-empty PkgPath.

This bug is new in 1.9. I suspect that it was introduced by https://golang.org/cl/35732.