Looks good
================
Comment at: lib/AST/MicrosoftMangle.cpp:2765
@@ +2764,3 @@
+ Linkage L = RD->getLinkageInternal();
+ if (L == InternalLinkage || L == UniqueExternalLinkage) {
+ // This part of the identifier needs to be unique across all translation
----------------
What about NoLinkage, which I believe applies to types declared in functions?
This check appears equivalent to !RD->isExternallyVisible(), which I think is
probably what you want.
This is the test case I'm imagining:
foo.h:
struct A { virtual int f(); };
void use_a(A&);
a.cpp:
static void f() { struct B : A { virtual int f() { return 1; } } b; use_a(b);
}
b.cpp:
static void f() { struct B : A { virtual int f() { return 2; } } b; use_a(b);
}
It seems like you'd need two distinct tags for B, right?
================
Comment at: lib/CodeGen/MicrosoftCXXABI.cpp:1701-1705
@@ -1600,3 +1700,7 @@
MicrosoftVTableContext::MethodVFTableLocation ML =
CGM.getMicrosoftVTableContext().getMethodVFTableLocation(GD);
+ if (CGF.SanOpts.has(SanitizerKind::CFIVCall))
+ CGF.EmitVTablePtrCheck(getClassAtVTableLocation(getContext(), GD, ML),
+ VTable, CodeGenFunction::CFITCK_VCall, Loc);
+
----------------
Sigh. I wish we didn't have to do this. We should be able to provide the record
decl that originally established the vftable slot in the method location, but
it's not easy and requires a good understanding of the MS vftable code, which
is pretty opaque. So let's do this for now.
I guess your algorithm also computes something subtly different. In this
example, you'll get B when calling f:
struct A { virtual void f(); };
struct B : A { virtual void g(); };
Whereas I would think of it as being the vftable introduced by A.
http://reviews.llvm.org/D10520
EMAIL PREFERENCES
http://reviews.llvm.org/settings/panel/emailpreferences/
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits