tree ff996f699e095923367a3733315b8254ec7770e3
parent eaf4afbabcd91df55d31955500b6db55b07f6de5
author Ian Lance Taylor <iant@golang.org> 1496891211 -0700
committer Ian Lance Taylor <iant@golang.org> 1496939945 +0000

compiler: fix undefined symbol error with unexported method

When an interface I1 in an imported package has an unexported method,
and is then embedded into another interface I2, in a different
package, that has other methods, and a type T2 is converted to I2, we
failed to ever define the required interface method table.  Naturally
T2 must implement the unexported method, and must therefore either be
defined in the same package as I1, or embed a type from that package.
In this case the compiler was assuming that that package would define
the interface method table, but of course, since I2 was not defined in
that package, that did not happen.

The fix is to only assume that the interface method table will be
defined elsewhere in the case where T2 and I2 are defined in the same
package.  The compiler ensures that all such interface method tables
are created, in Gogo::build_interface_method_tables.  This requires
knowing the package in which an interface type is defined, a simple
tweak to the importer.

Testing this revealed that the special case for stub methods created
for the embedded unexported methods of T2 needs to be done for
function declarations as it currently is for function definitions, so
that the newly created interface method tables use the correct name.

Testing that revealed that the code to determine the pkgpath symbol
for such stub methods was wrong.  It assumed that one could call
pkgpath_for_symbol on the pkgpath to get the pkgpath symbol.  Would
that it twere so simple.  Instead, add a function to look up the
package, which must be known, and fetch the pkgpath symbol.

The test for this is https://golang.org/cl/45085.

Change-Id: Ib7c47f0758c20393f99c6f0e612536ee08a5aaa2
Reviewed-on: https://go-review.googlesource.com/45086
Reviewed-by: Than McIntosh <thanm@google.com>