On Sat, Nov 29, 2025 at 06:37:03PM +0530, Jason Merrill wrote:
> > > > + /* Some metafunctions aren't dependent just on their arguments, but
> > > > also
> > > > + on various other dependencies, e.g. has_identifier on a function
> > > > parameter
> > > > + reflection can change depending on further declarations of
> > > > corresponding
> > > > + function, is_complete_type depends on type definitions and
> > > > template
> > > > + specializations in between the calls, define_aggregate even
> > > > defines
> > > > + class types, etc. Thus, we need to arrange for calls which call
> > > > + at least some metafunctions to be non-cacheable, because their
> > > > behavior
> > > > + might not be the same. Until we figure out which exact
> > > > metafunctions
> > > > + need this and which don't, do it for all of them. */
> > > > + bool metafns_called;
> > >
> > > Maybe instead we need more calls to clear_cv_and_fold_caches?
> >
> > But when? During completion of any type, any redeclaration of a function,
> > and many other conditions which can change behavior of some metafunctions?
> > Any additions of decls to namespaces would be another change, etc.
> > On the other side, do we to clear the caches in all such spots even when
> > none of the metafunctions have been used in anything that has been cached?
>
> Currently we clear the caches when defining an enum or a variable; it seems
> reasonable to also do it for other declarations/definitions.
For those we only clear the cv_cache and fold_cache. We never clear
constexpr_call_table.
So, do you want to clear the whole constexpr_call_cache if (flag_reflection)
in the various cases that can change the metafunction behavior
1) defining enum
2) defining a class
3) during duplicate_decls
and wherever else we find a problem? Currently with
- ctx->global->metafns_called = true;
+// ctx->global->metafns_called = true;
only
FAIL: g++.dg/reflect/enumerators_of1.C -std=c++26 (test for excess errors)
FAIL: g++.dg/reflect/p2996-17.C -std=c++26 (test for excess errors)
failures appear, but that is mostly because in most tests (with the main
exception of the various
consteval bool
whatever (info r)
{
try { whatever_metafn (r); }
catch (std::meta::exception &) { return false; }
return true;
}
functions) call metafunctions directly rather than through a chain of other
constexpr functions. enumerators_of1.C fails exactly because of the missing
clearing of the constexpr_call_cache when defining an enum. I will try to
construct a testcase where it will fail because of the duplicate_decls case
(has_identifier changing one way or the other on redeclarations of the same
decl; we have tests for it but likely all direct and we don't cache calls
to metafns in constexpr_call_cache). The p2996-17.C case is about the class
type completions, but it is using define_aggregate, so another question is
if it is safe to clear the constexpr_call_cache from within a constexpr
call evaluation, but maybe it is as it is GC allocated and so we could
in the callers just store something that nothing else will find.
Or, shall we record in constexpr_call_cache whether a call called any
metafunctions (so keep the metafns_called flag and remember it, just don't
use it for cacheable = false) and only flush on 1)/2)/3) etc. just the
calls that called any metafns?
Jakub
