Why don't we just FIX the damn vthunk problem?

[Martin v. Loewis]

> Wouldn't it?  I don't see that.  Seems to me we could do the same thing,
> again copying out the array address on the way up and storing on the way
> down.  The A vptr isn't any more stable than the (hypothetical) B vptr at
> that point.  It's also somewhat more elegant to point to various options
> for the A vptr from the A vptr...
> 
> What am I missing?

That's an ABI change, isn't it? If the derived class is old code, and
the base class is recompiled, it'll crash - it gets a vtable ptr in
_vptr instead of a vtable array. I'm not sure whether it works the
other way 'round, it seems it does (at least as good as it does now).

I much prefer if incompatible code won't link: Replace the implicit
'int in_chrg' with an implicit 'void *vtable_list'. Passing 0 as this
argument indicates we are the most derived class, passing a pointer to
the array is for base classes. If necessary, we can emit the current
implicit-int constructor with delegation to the new ABI as a limited
form of backwards-compatibility, and abort() if this gets called from
a derived class.

Regards,
Martin