https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102753
--- Comment #3 from CVS Commits <cvs-commit at gcc dot gnu.org> --- The master branch has been updated by Jakub Jelinek <ja...@gcc.gnu.org>: https://gcc.gnu.org/g:4b2fda8bea3fdcc9421726e5a21e537f745cad0b commit r12-4730-g4b2fda8bea3fdcc9421726e5a21e537f745cad0b Author: Jakub Jelinek <ja...@redhat.com> Date: Wed Oct 27 09:03:28 2021 +0200 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 <ja...@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.
