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 > > > > > >
