On Tue, Oct 22, 2019 at 09:52:44AM -0400, Jason Merrill wrote:
> 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.
The other ones just call it regardless of processing_template_decl.
The reason for !processing_template_decl would be that otherwise
tsubst_requires_expr calls finish_requires_expr which would already call the
finish_unevaluated_operand. Though, I'm afraid it is unclear to me
where to call finish_unevaluated_operand in tsubst_requires_expr,
as we need to call it on a tsubsted expression (it was already called
on the non-tsubsted one), but it looks like tsubst_requirement_body
returns error_mark_node both in cases where there is some substitution
failure diagnosed, or when there is some failure. And we don't call
tsubst_requirement_body at all if tsubst_constraint_variables fails.
> > In fact, the above with TREE_STATIC isn't enough, because
> > we perform cp_fold on non-TREE_STATIC initializers
>
> Is that a problem?
If we cxx_eval_consteval first, then it isn't a problem I guess at least
for the consteval stuff. Though, e.g. the initializer could contain
in constexpr functions expressions that during constexpr evaluation would
need to be diagnosed and cp_fold would make that go away. Say out of bounds
access to something that cp_fold happily folds away.
> > 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.
Ok.
Jakub
