diff options
author | Faisal Vali <faisalv@yahoo.com> | 2017-08-27 02:21:21 +0000 |
---|---|---|
committer | Faisal Vali <faisalv@yahoo.com> | 2017-08-27 02:21:21 +0000 |
commit | 13624cf98053ea40edbd49c9431c97dc56dcd29a (patch) | |
tree | b65efc3da99e4e77aba9d957c06869619fb3e503 /clang/lib/CodeGen/ModuleBuilder.cpp | |
parent | 9bdccb37d5aafc18cf9da1267f4f59d271a4f3b2 (diff) | |
download | llvm-13624cf98053ea40edbd49c9431c97dc56dcd29a.zip llvm-13624cf98053ea40edbd49c9431c97dc56dcd29a.tar.gz llvm-13624cf98053ea40edbd49c9431c97dc56dcd29a.tar.bz2 |
Pass the correct object argument when a member call to an 'unrelated' class is made.
Prior to this patch, clang would do the wrong thing here (see inline comments for pre-patch behavior):
struct A {
void bar(int) { }
static void bar(double) { }
void g(int*);
static void g(char *);
};
struct B {
void f() {
A::bar(3); // selects (double) ??!!
A::g((int*)0); // Instead of no object argument, states conversion error?!!
}
};
The fix is as follows: When we detect that what appears to be an implicit member function call (A::bar) is actually a call to a member of a class (A) unrelated to the type (B) that contains the member function (B::f) from which the call is being made, don't treat it (A::bar) as an Implicit Member Call Expression.
P.S. I wonder if there is an existing bug report related to this? (Surprisingly, a cursory search did not find one).
llvm-svn: 311839
Diffstat (limited to 'clang/lib/CodeGen/ModuleBuilder.cpp')
0 files changed, 0 insertions, 0 deletions