cmd/compile: wrong logic for pkg derivation of unnamed type

[rsc]

Happened to be working in cmd/compile/internal/gc/reflect.go and saw:

		// Unnamed type. Grab the package from the first field, if any.
		for _, f := range t.Fields().Slice() {
			if f.Embedded != 0 {
				continue
			}
			pkg = f.Sym.Pkg
			break
		}

I don't believe this is completely correct. There is no guarantee that the first non-embedded field will have a package. The commit message refers to

struct { i int }

which the code handles correctly, but I think the code still mishandles

struct { X int; i int }

because it will look at X, which has no Pkg, instead of at i, which does. It should probably continue the loop until it finds something with a pkg.

/cc @crawshaw @griesemer @mdempsky

[mdempsky]

From what I can tell, the package we select there is just for a space optimization. Picking the wrong package means we waste space in the reflect type information tables (and thus should still be fixed), but I don't think it affects correctness at least.

[rsc]

@mdempsky the test in CL 27791, which introduced this code, is testing semantics observable via reflect and mentions #16616, so I don't think this is only about space usage.

[ianlancetaylor]

It's not obvious to me that anything is wrong here. The f.Sym.Pkg field here is a compiler internal data structure. It's not the same as the reflect data. The fact that exported fields have no package in the reflect data is handled later, in dnameField.

[mdempsky]

@rsc fixedbugs/issue16616.go still passes after removing that loop though.

[gopherbot]

Change https://golang.org/cl/60410 mentions this issue: cmd/compile: fix and improve struct field reflect information