On Tue, Oct 22, 2019 at 3:15 AM Jakub Jelinek <ja...@redhat.com> wrote: > > On Mon, Oct 21, 2019 at 04:44:22PM -0400, Jason Merrill wrote: > > Perhaps we should bypass the existing virtual function call mechanism for > > consteval, and instead find the complete object directly and call > > non-virtually. > > Maybe, but can that be done incrementally?
Certainly. > > > The finish_function was just an attempt to limit the number of places > > > where > > > we need to call it to a minimum. > > > > Fair enough. Maybe just a finish_unevaluated_operand then. > > Good idea, added. > > Apparently there is one unevaluated operand I've missed, requires > expression, but I don't know anything about concepts. Do we need to call > finish_unevaluated_operand from finish_requires_expr and tsubst_requires_expr Sounds good. > (the latter perhaps just if !processing_template_decl)? I'd think we would want to be consistent with other immediate invocations in template context. > Are the requires params to be treated as non-constexpr entities (so e.g. > passing them to a > consteval function would be an error)? That's an open question, but let's assume so for now. > > > + if (init && TREE_STATIC (decl)) > > > + init = cxx_eval_consteval (init); > > > > Do we need this in addition to the cxx_constant_init in store_init_value? > > cxx_constant_init indeed can handle immediate invocations when it encounters > them while evaluating the constant expression, like maybe_constant_value > etc. cxx_constant_init is not called on all initializers though, > maybe_constant_value is called on others, and my understanding of consteval > is that immediate invocations need to be evaluated anywhere in the > expressions, not just in the subexpressions encountered during constexpr > evaluation. Good point. > In fact, the above with TREE_STATIC isn't enough, because > we perform cp_fold on non-TREE_STATIC initializers Is that a problem? > (maybe we shouldn't and defer that to cp_fold_function?) I think it's done early now for the sake of constant evaluation later in the function, but perhaps that's not necessary anymore. > it is needed also for non-TREE_STATIC > initializers, but even for TREE_STATIC, the first point is avoid evaluating > immediate invocations multiple times and second ensure they are evaluated > everywhere. The way cxx_eval_consteval is written, it doesn't hurt if > it is called multiple times, because it replaces the immediate evaluations > with their constant values or void/zero constant (if errors were detected). > > I've added a whole new testcase (consteval11.C) which covers > in 0 ? immediate_invocation : ... etc. and made the check_initializer > changes that were needed for that. Am not 100% sure about the > diagnostics in consteval function when it is initializer of a constexpr > function, but I believe in that case it isn't treated as immediate > invocation, just normal call during constexpr processing. > Now, I'm afraid I have no idea what is the right behavior if immediate > invocations appear in discarded statements. Guess we need testsuite > coverage for that too. Discarded statements aren't instantiated at all, so we shouldn't see immediate invocations there. Jason
