On Apr 6, 2013, at 3:44 PM, Reid Kleckner <[email protected]> wrote:
> + virtual void mangleCXXVBTable(const CXXRecordDecl *Derived,
> + llvm::ArrayRef<const CXXRecordDecl *>
> BasePath,
This needs to be a path of CXXBaseSpecifier*s. One, that's probably
more straightforward to create, and two, there's an ambiguity here that
it'd clean up.
For example:
struct A { int x; };
struct B : virtual A {}; // vbptrs: B
struct C : virtual B {}; // vbptrs: C, virtual B in C
struct D : B, C {}; // vbptrs: B in D, C in D, virtual B in D
Incidentally, how would these actually be mangled?
> +bool CXXRecordDecl::hasDirectVirtualBase() const {
> + for (CXXRecordDecl::base_class_const_iterator I = this->bases_begin(),
> + E = this->bases_end(); I != E; ++I) {
> + if (I->isVirtual())
> + return true;
> + }
> + return false;
> +}
> +
I really doubt you actually need this.
> + // If Base is the only non-virtual base of its parent, we can skip this
> + // link in the path and still guarantee that this is a unique symbol.
> + if ((*I)->getNumBases() == 1 && !(*I)->hasDirectVirtualBase())
> + continue;
This is just ((*)->getNumBases() == 1 && !(*(*I)->bases_begin())->isVirtual()),
but I'm very skeptical about this computation.
The deep question here, which I can't really answer myself without seeing
tests, is when, exactly, MSVC adds base-path information to the mangling?
If I were designing this, I would add it only when a class has multiple
non-virtual
bases, and I would only add it to "secondary" vb-tables — i.e. to vb-tables that
are not the "primary" vb-table, i.e. not the one that I would add the new
entries
to if my class added new virtual bases. And I'd need some way to distinguish
paths that correspond to morally virtual base sub-objects, e.g. to handle my
test case above.
John.
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
