This is the mail archive of the gcc-cvs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

r249024 - in /trunk/gcc/go/gofrontend: MERGE ex...


Author: ian
Date: Thu Jun  8 16:40:21 2017
New Revision: 249024

URL: https://gcc.gnu.org/viewcvs?rev=249024&root=gcc&view=rev
Log:
    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.
    
    Reviewed-on: https://go-review.googlesource.com/45086

Modified:
    trunk/gcc/go/gofrontend/MERGE
    trunk/gcc/go/gofrontend/expressions.cc
    trunk/gcc/go/gofrontend/gogo.cc
    trunk/gcc/go/gofrontend/gogo.h
    trunk/gcc/go/gofrontend/types.cc
    trunk/gcc/go/gofrontend/types.h


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]