On Sun, Jun 21, 2026 at 12:31:30PM -0400, Jason Merrill wrote:
> On 6/18/26 5:15 PM, Jakub Jelinek wrote:
> > On Thu, Jun 18, 2026 at 04:37:44PM -0400, Jason Merrill wrote:
> > > On 6/18/26 3:20 PM, Marek Polacek wrote:
> > > > Currently, we include all the built-ins like __builtin_fdimf32x in
> > > > the result of members_of. We probably should skip them. This patch
> > > > uses DECL_IS_UNDECLARED_BUILTIN so that we skip __builtin_abs but
> > > > include abs.
> > > >
> > > > On ^^:: this reduces the # of elements from 2591 to 653.
> > > >
> > > > PR c++/125819
> > > >
> > > > gcc/cp/ChangeLog:
> > > >
> > > > * reflect.cc (namespace_members_of): Skip
> > > > DECL_IS_UNDECLARED_BUILTIN functions.
> > >
> > > Why only functions? I'd think we want to skip all kinds of built-in
> > > decls.
> >
> > I think it would be weird if builtins are hidden from members_of (sure, the
> > __integer_pack can be an exception), users can use say
> > decltype (::__builtin_fdimf32x) etc. too, so why should we hide them from
> > users during reflection through which they can query them similarly?
>
> I expect people to use reflection to ask about the contents of the program
> rather than the compiler; for the latter there is __has_builtin. And as you
> mention in your followup, a lot of the built-ins don't play well with the
> C++ type system. It seems to me most consistent to just exclude them from
> members_of.
If people query members_of on ^^:: or ^^std, they need to be prepared
to see a lot of implementation specific stuff anyway, members_of can be only
used when including at least <meta> and that alone will include various
C library headers with various declarations in the global namespace.
So, in order to ask about the contents of the program rather than
implementation one needs to filter out stuff (e.g. based on source
locations).
Jakub
