c++: Diagnose taking address of an immediate member function [PR102753]

The consteval20.C testcase ICEs, because while we have in cp_build_addr_expr_1
diagnostics for taking address of an immediate function (and as an exception
deal with build_address from immediate invocation), I forgot to diagnose
taking address of a member function which is done in a different place.
I hope (s.*&S::foo) () is not an immediate invocation like
(*&foo) () is not, so this patch just diagnoses taking address of a member
function when not in immediate context.

On Mon, Oct 18, 2021 at 12:42:00PM -0400, Jason Merrill wrote:
> > --- gcc/cp/typeck.c.jj      2021-10-05 09:53:55.382734051 +0200
> > +++ gcc/cp/typeck.c 2021-10-15 19:28:38.034213437 +0200
> > @@ -6773,9 +6773,21 @@ cp_build_addr_expr_1 (tree arg, bool str
> >         return error_mark_node;
> >       }
> > +   if (TREE_CODE (t) == FUNCTION_DECL
> > +       && DECL_IMMEDIATE_FUNCTION_P (t)
> > +       && cp_unevaluated_operand == 0
> > +       && (current_function_decl == NULL_TREE
> > +           || !DECL_IMMEDIATE_FUNCTION_P (current_function_decl)))
>
> This doesn't cover some of the other cases of immediate context; we should
> probably factor most of immediate_invocation_p out into a function called
> something like in_immediate_context and use it here, and in several other
> places as well.

You're right, I've done that for the two spots in cp_build_addr_expr_1
and added testsuite coverage for where it changed behavior.
While doing that I've discovered further issues.

One is that we weren't diagnosing PMFs referring to immediate methods
returned from immediate functions (either directly or embedded in
aggregates).  I'm not sure if it can only appear as PTRMEM_CST which
I've handled (cp_walk_subtree only walks the type and not the
PTRMEM_CST_MEMBER) or something else.

Another issue is that while default arg in immediate function
containing &immediate_fn works properly, if it is immediate_fn
instead, we were incorrectly rejecting it.
I've handled this in build_over_call, though with this usage
in_consteval_if_p is slightly misnamed, it stands for in consteval
if or some other reason why we are currently in immediate function context.
Though, that flag alone can't be all the reasons for being in immediate
function contexts, as I've tried the other reasons can't be handled in such
a bool and need to be tested too.

2021-10-27  Jakub Jelinek  <jakub@redhat.com>

	PR c++/102753
	* cp-tree.h (saved_scope): Document that consteval_if_p member
	is also set while processing immediate invocation.
	(in_immediate_context): Declare.
	* call.c (in_immediate_context): New function.
	(immediate_invocation_p): Use it.
	(struct in_consteval_if_p_temp_override): New class.
	(build_over_call): Temporarily set in_consteval_if_p for processing
	immediate invocation arguments.
	* typeck.c (cp_build_addr_expr_1): Diagnose taking address of
	an immediate method.  Use t instead of TREE_OPERAND (arg, 1).
	Use in_immediate_context function.
	* constexpr.c (find_immediate_fndecl): Handle PTRMEM_CST
	which refers to immediate function decl.

	* g++.dg/cpp2a/consteval13.C: Don't expect errors.
	* g++.dg/cpp2a/consteval20.C: New test.
	* g++.dg/cpp2a/consteval21.C: New test.
	* g++.dg/cpp2a/consteval22.C: New test.
	* g++.dg/cpp2a/consteval23.C: New test.
	* g++.dg/cpp23/consteval-if11.C: New test.

0 files changed, 0 insertions, 0 deletions