Covariant returns

[Jason Merrill]

Mark Mitchell <mark at codesourcery.com> writes:

> Although the closed issues list discusses covariant returns, the ABI
> document itself does not.  It looks like we agreed on providing
> alternate entry points for non-trivial covariant returns.  In that
> case, we need to specify the order in the vtable in which such entries
> appear.

I don't think we do.  The only case where we would need an additional
entry point would be when the function is coming from a secondary
vtable.  But we are already promoting vtable entries from secondary
vtables into primary vtables; that entry should point to the covariant
return entry point.

No, I take it back.  If the return types are not simply pointers to
the classes in which the functions are defined, but some other
pair of related types, then we might need a return adjustment in a
case where we wouldn't need a 'this' adjustment.

In that case, I would suggest just adding the new entry at the end of
the vtable, just as if the function were new.

> Since we also provide a copy of a virtual function in the primary
> vtable when a derived class overrides a virtual function from a
> secondary base, we need to know whether to make copies of all the
> entry points, or just the one with the same signature as that
> provided in the derived class.

Each class type should have exactly one entry point for a particular
virtual function.  In the case mentioned above, we might have two
entry points in the primary vtable, but one would only be referred to
through a pointer to the base type.

> There also need to be vcall offsets for all of the covariant
> returns.

Why would we need anything that we wouldn't already need for functions
without covariant returns?

Jason