https://gcc.gnu.org/bugzilla/show_bug.cgi?id=124628
--- Comment #4 from GCC Commits <cvs-commit at gcc dot gnu.org> --- The master branch has been updated by Patrick Palka <[email protected]>: https://gcc.gnu.org/g:05ea83ffd5409243902e1129e1e67ad7cff3afa6 commit r17-517-g05ea83ffd5409243902e1129e1e67ad7cff3afa6 Author: Patrick Palka <[email protected]> Date: Thu May 14 14:53:06 2026 -0400 c++/reflection: undeduced auto, deferred noexcept [PR124628] Various reflection queries reject functions (or variables) with an undeduced return type. But this assumes return type deduction has already been attempted which is not the case if the function is a specialization that has not yet been ODR-used or otherwise instantiated, which we must do now. Similarly a function can also have an deferred noexcept-specification which we should also instantiate at this point. Rather an inventing a new way to resolve the type of such a function or variable for reflection purposes, I think we can just silently call mark_used in an unevaluated context, which will behave similarly to requires { &decl; }. Since diagnostics (in the immediate context) get suppressed, we'll gracefully handle deleted functions or those with unsatisfied constraints, leaving it up to the caller to handle them. PR c++/124628 gcc/cp/ChangeLog: * reflect.cc (resolve_type_of_reflected_decl): New. (get_reflection): Call resolve_type_of_reflected_decl instead of mark_used. (has_type): Call resolve_type_of_reflected_decl before checking for an undeduced auto. (eval_can_substitute): Likewise. Also look through BASELINK. (members_of_representable): Call resolve_type_of_reflected_decl before checking for an undeduced auto. gcc/testsuite/ChangeLog: * g++.dg/reflect/can_substitute2.C: New test. * g++.dg/reflect/members_of14.C: New test. * g++.dg/reflect/substitute3.C: Adjust test so that f<int>'s return type fails to get deduced. * g++.dg/reflect/type_of3.C: Also test type_of of a templated member function with deduced return type. Reviewed-by: Jason Merrill <[email protected]> Reviewed-by: Marek Polacek <[email protected]>
