maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/llgo/test/irgen/mangling-synthetic.go

15 lines
460 B
Go
Raw Normal View History

Use the object's package to mangle method names, rather than the receiver's package If we use the receiver's package, we can end up with identical manglings for different functions. Consider: package p type U struct{} func (U) f() package q import "p" type T struct { p.U } func (T) f() The method set of *T has two synthetic methods named (*T).f(); one forwards to (T).f(), and the other to (U).f(). Previously, we were distinguishing them by the receiver's package, and in this case because both methods have the same receiver, they received the same name. The methods are correctly distinguished by the package owning the identifier "f", which is available via f.Object().Pkg(). Differential Revision: http://reviews.llvm.org/D6673 llvm-svn: 224357
2014-12-17 04:04:55 +08:00
// RUN: llgo -fgo-pkgpath=p -c -o %T/p.o %S/Inputs/mangling-synthetic-p.go
// RUN: llgo -fgo-pkgpath=q -I %T -S -emit-llvm -o - %s | FileCheck %s
package q
import "p"
Roll gofrontend to 07baa07598ea; roll libffi to r219477. Incorporates https://codereview.appspot.com/198770044, which causes us to start using the static chain register for closures instead of __go_{get,set}_closure. Differential Revision: http://reviews.llvm.org/D8829 llvm-svn: 234135
2015-04-06 07:31:49 +08:00
// CHECK-DAG: define linkonce_odr void @p.f.N3_q.T(i8* nest, i8*)
// CHECK-DAG: define linkonce_odr void @p.f.pN3_q.T(i8* nest, i8*)
Use the object's package to mangle method names, rather than the receiver's package If we use the receiver's package, we can end up with identical manglings for different functions. Consider: package p type U struct{} func (U) f() package q import "p" type T struct { p.U } func (T) f() The method set of *T has two synthetic methods named (*T).f(); one forwards to (T).f(), and the other to (U).f(). Previously, we were distinguishing them by the receiver's package, and in this case because both methods have the same receiver, they received the same name. The methods are correctly distinguished by the package owning the identifier "f", which is available via f.Object().Pkg(). Differential Revision: http://reviews.llvm.org/D6673 llvm-svn: 224357
2014-12-17 04:04:55 +08:00
type T struct { p.U }
Roll gofrontend to 07baa07598ea; roll libffi to r219477. Incorporates https://codereview.appspot.com/198770044, which causes us to start using the static chain register for closures instead of __go_{get,set}_closure. Differential Revision: http://reviews.llvm.org/D8829 llvm-svn: 234135
2015-04-06 07:31:49 +08:00
// CHECK-DAG: declare void @q.f.N3_q.T(i8* nest, i8*)
// CHECK-DAG: define linkonce_odr void @q.f.pN3_q.T(i8* nest, i8*)
Use the object's package to mangle method names, rather than the receiver's package If we use the receiver's package, we can end up with identical manglings for different functions. Consider: package p type U struct{} func (U) f() package q import "p" type T struct { p.U } func (T) f() The method set of *T has two synthetic methods named (*T).f(); one forwards to (T).f(), and the other to (U).f(). Previously, we were distinguishing them by the receiver's package, and in this case because both methods have the same receiver, they received the same name. The methods are correctly distinguished by the package owning the identifier "f", which is available via f.Object().Pkg(). Differential Revision: http://reviews.llvm.org/D6673 llvm-svn: 224357
2014-12-17 04:04:55 +08:00
func (T) f()