[PATCH] Get rid of VTableContext::ComputeMethodVTableIndices() and VTableContext::getNumVirtualFunctionPointers()

[Richard Smith]

On Mon, May 13, 2013 at 10:04 PM, Timur Iskhodzhanov <timurrrr at google.com>wrote:

>
>
> ================
> Comment at: lib/AST/VTableBuilder.cpp:2319
> @@ -2318,3 @@
> -    //   If a class has an implicitly-defined virtual destructor,
> -    //   its entries come after the declared virtual function pointers.
> -
> ----------------
> Richard Smith wrote:
> > Timur Iskhodzhanov wrote:
> > > Reid Kleckner wrote:
> > > > Timur Iskhodzhanov wrote:
> > > > > Reid Kleckner wrote:
> > > > > > I don't think Test16::D triggers this case because ~D is
> overriding ~C, so it goes into the vtable first.
> > > > > >
> > > > > > When can you have an implicitly defined virtual dtor without
> overriding the method of a base class?  Is that possible? Good question for
> Richard or John.
> > > > > Err, no.
> > > > > There's no ~D in Test16:D.
> > > > >
> > > > >   struct C : ... { virtual ~C(); };
> > > > >   struct D : virtual C {
> > > > >     virtual void f();
> > > > >   };
> > > > >
> > > > > So C has virtual ~C, thus D should have a virtual dtor.
> > > > > AFAIU, as there's no explicit ~D, there should be an implicit one.
> > > > >
> > > > > Does that sound right?
> > > > Yes, it's implicit, but it wasn't triggering this code, because it
> should always hit the codepath for overrides and continue the loop before
> setting ImplicitVirtualDtor.  I'm looking for a counterexample to show that
> this code isn't dead.
> > > Errr, it **was** trigerring this code.
> > >
> > > I found it by locally replacing the below
> > >
> > >   if (isMicrosoftABI()) {
> > >
> > > with
> > >
> > >   if (1) {
> > >
> > > and it did report an error on Test16::D
> > If any base class of a class X has a virtual destructor, then X also has
> a virtual destructor, no matter whether it's declared explicitly or
> implicitly. If no base class of X has a virtual destructor, and X does not
> declare a destructor, then its implicit destructor is not virtual. Does
> that answer the question?
> Almost, thanks!
>
> Am I right that if a virtual base class V of a class X has a virtual
> destructor and X doesn't have an explicitly defined dtor, Sema will put ~X
> at the end of X `CXXRecordDecl`'s method list (as one can only tell there's
> no explicit ~X at the end of X's definition)?


It is not guaranteed to be at the end of the method list, and we don't want
to provide that guarantee. (As it happens, it often will be at the end, but
in practice we could add some implicitly-declared constructors after it.)
As for any implicitly-declared special member, we will only add it once we
get to the end of parsing the class.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130513/cc42ed11/attachment.html>