On Fri, Sep 14, 2018 at 04:30:46PM -0400, Jason Merrill wrote:
> On Fri, Sep 14, 2018 at 1:19 PM, Marek Polacek <pola...@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
