Jacobson's email was treated as spam somehow. Sorry for missing your email.

On Mon, Mar 27, 2023 at 2:59 PM Jonathan Wakely <jwak...@redhat.com> wrote:
>
> On Sat, 25 Mar 2023 at 12:23, Roy Jacobson via Libstdc++
> <libstd...@gcc.gnu.org> wrote:
> >
> > Clang has been providing __is_void for a very long time now, and is
> > definitely compatible with libstdc++. Does defining this builtin cause a
> > problem? Might be that the lookup rules for builtins are different or
> > something.
> >
> > https://clang.llvm.org/docs/LanguageExtensions.html#type-trait-primitives
>
> Clang has special hacks that allow it to handle libstdc++ headers.
> When it sees the use of a built-in trait like __is_void used as an
> identifier, it disables the built-in and treats it as a normal
> identifier for the rest of the translation unit. GCC doesn't do that,
> so "it compiles with Clang" isn't really relevant here.
>
>
> >
> > On Sat, 25 Mar 2023 at 15:08, Ken Matsui via Gcc <gcc@gcc.gnu.org> wrote:
> >
> > > Hi,
> > >
> > > I am working on the GSoC project, "C++: Implement compiler built-in
> > > traits for the standard library traits".
> > >
> > > Built-in trait naming simply adds two underscores (__) to the original
> > > trait name. However, the same names are already in use for some
> > > built-in traits, such as is_void, is_pointer, and is_signed.
> > >
> > > For example, __is_void is used in the following files:
> > >
> > > * gcc/testsuite/g++.dg/tm/pr46567.C
> > > * libstdc++-v3/include/bits/cpp_type_traits.h
> > >
> > > In this case, are we supposed to change the existing same name in the
> > > code to something like ____is_void (four underscores)? Or is it better
> > > to break the naming convention of built-in traits like
> > > __is_void_builtin?
> > >
> > > Sincerely,
> > > Ken Matsui
> > >
> >
>

Reply via email to