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.
> 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...
Jason
