[Bug c++/88335] Implement P1073R3, C++20 immediate functions (consteval).

[jason at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88335

--- Comment #15 from Jason Merrill <jason at redhat dot com> ---
On 11/28/19 12:58 PM, jakub at gcc dot gnu.org wrote:
> Now, the issues:
> 1) (so far ignored); the standard says that classes where all virtual members are immediate are still polymorphic,
>     but I guess for the ABI we don't want a vtable pointer there.  So, I think we want TYPE_POLYMORPHIC_P set on
>     those, but e.g. TYPE_CONTAINS_VPTR_P probably shouldn't be true for them; do we want TYPE_REALLY_POLYMORPHIC_P or
>     similar for polymorphic types that contain at least one non-immediate virtual function and thus need a vtable?

We still need a vtable for typeinfo, so I think we don't need to worry 
about this.

> 2) initially I thought I'd just always emit a direct call to the immediate
> virtual method found by lookup and do the  remapping of that during constexpr call evaluation; unfortunately as the
> v->S::bar () etc. calls show, we only want to do that if LOOKUP_NONVIRTUAL wasn't set; unfortunately, when immediate
> functions aren't in the binfo structures, DECL_VINDEX is error_mark_node and so I think we need some hack how to
> preserve the info that we are going to call a virtual consteval method; could we e.g. abuse OBJ_TYPE_REF with
> different arguments that would make it clear it is something different, or new tree?  We need to store the instance
> on which it is called and the virtual consteval method originally chosen e.g. to compare the type

> 3) I'm afraid one can't use a lookup_member on the actual instance type, because it could find all kinds of things,
>     static member functions, typedefs, data members etc. in derived classes, where we actually are only interested in
>     in virtual methods.  So, shall we use something like look_for_overrides does, except with the fndecl from the
>     base rather than derived and of course don't do anything except return the first found method (and ignore static member
>     functions rather than handling them)?

Would it work to include them at the end of BINFO_VIRTUALS but omit them 
in build_vtbl_initializer?

> 4) guess covariant returns need to be handled at the end too somehow

Yep.

Jason