Re: C++ PATCH to implement P1064R0, Virtual Function Calls in Constant Expressions

[Marek Polacek <polacek at redhat dot com>]

On Fri, Sep 14, 2018 at 04:30:46PM -0400, Jason Merrill wrote:
> On Fri, Sep 14, 2018 at 1:19 PM, Marek Polacek <polacek@redhat.com> wrote:
> > This patch implements another bit of C++20, virtual calls in constant
> > expression:
> > <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1064r0.html>
> > The basic idea is that since in a constant expression we know the dynamic
> > type (to detect invalid code etc.), the restriction that prohibits virtual
> > calls is unnecessary.
> >
> > Handling virtual function calls turned out to be fairly easy (as anticipated);
> > I simply let the constexpr machinery figure out the dynamic type and then
> > OBJ_TYPE_REF_TOKEN gives us the index into the virtual function table.  That
> > way we get the function decl we're interested in, and cxx_eval_call_expression
> > takes it from there.
> >
> > But handling pointer-to-virtual-member-functions doesn't work like that.
> > get_member_function_from_ptrfunc creates a COND_EXPR which looks like
> > if (pf.__pfn & 1) // is it a virtual function?
> >   // yes, find the pointer in the vtable
> > else
> >   // no, just return the pointer
> > so ideally we want to evaluate the then-branch.  Eventually it'll evaluate it
> > to something like _ZTV2X2[2], but the vtable isn't constexpr so we'd end up
> > with "not a constant expression" error.
> 
> Then let's mark the vtable as constexpr, there's no reason for it not to be.

Ok, unfortunately it wasn't as easy as merely marking it DECL_DECLARED_CONSTEXPR_P
in initialize_artificial_var because then I saw "used in its own initializer"
error.  Which I don't know why, but now that I know you agree with this direction
I can dig deeper.
 
> > Since the vtable initializer is
> > a compile-time constant, I thought we could make it work by a hack as the one
> > in cxx_eval_array_reference.  We'll then let cxx_eval_call_expression do its
> > job and everything is hunky-dory.
> >
> > Except when it isn't: I noticed that the presence of _vptr doesn't make the
> > class non-empty, and when cxx_eval_constant_expression saw a decl with an empty
> > class type, it just evaluated it to { }.  But such a class still had gotten an
> > initializer that looks like {.D.2082 = {._vptr.X2 = &_ZTV2X2 + 16}}.  So
> > replacing it with { } will lose the proper initializer whereupon we fail.
> > The check I've added to cxx_eval_constant_expression won't win any beauty
> > contests but unfortunately EMPTY_CONSTRUCTOR_P doesn't work there.
> 
> Perhaps we should check !TYPE_POLYMORPHIC_P as well as
> is_really_empty_class.  Perhaps there should be a predicate for that,
> say, is_really_nearly_empty_class...

Ack.  Thanks,

Marek