[GSoC] Conflicted Built-in Trait Name

[GSoC] Conflicted Built-in Trait Name

[Ken Matsui]

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

Re: [GSoC] Conflicted Built-in Trait Name

[Roy Jacobson]

[-- Attachment #1: Type: text/plain, Size: 1100 bytes --]

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

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
>

Re: [GSoC] Conflicted Built-in Trait Name

[Marc Glisse]

On Sat, 25 Mar 2023, Ken Matsui via Gcc wrote:

> 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

This is a testcase, you can rename __is_void to whatever in there, it 
doesn't matter.

> * libstdc++-v3/include/bits/cpp_type_traits.h

This __is_void seems to be used in a single place in 
include/debug/helper_functions.h, couldn't we tweak that code so __is_void 
becomes unused and can be removed?

-- 
Marc Glisse

Re: [GSoC] Conflicted Built-in Trait Name

[Ken Matsui]

On Sat, Mar 25, 2023 at 5:38 AM Marc Glisse <marc.glisse@inria.fr> wrote:
>
> On Sat, 25 Mar 2023, Ken Matsui via Gcc wrote:
>
> > 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
>
> This is a testcase, you can rename __is_void to whatever in there, it
> doesn't matter.
>
> > * libstdc++-v3/include/bits/cpp_type_traits.h
>
> This __is_void seems to be used in a single place in
> include/debug/helper_functions.h, couldn't we tweak that code so __is_void
> becomes unused and can be removed?

That worked. Thank you!

So, we can remove a code in a header as long as it is not standard and
is not used elsewhere, can't we?

Re: [GSoC] Conflicted Built-in Trait Name

[François Dumont]

On 26/03/2023 04:01, Ken Matsui via Libstdc++ wrote:
> On Sat, Mar 25, 2023 at 5:38 AM Marc Glisse <marc.glisse@inria.fr> wrote:
>> On Sat, 25 Mar 2023, Ken Matsui via Gcc wrote:
>>
>>> 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
>> This is a testcase, you can rename __is_void to whatever in there, it
>> doesn't matter.
>>
>>> * libstdc++-v3/include/bits/cpp_type_traits.h
>> This __is_void seems to be used in a single place in
>> include/debug/helper_functions.h, couldn't we tweak that code so __is_void
>> becomes unused and can be removed?
> That worked. Thank you!
What worked ?
>
> So, we can remove a code in a header as long as it is not standard and
> is not used elsewhere, can't we?

You can do anything you like as long as you run the testsuite before 
presenting your patch. Here note that you'll need to run:

make check-debug

to run tests in _GLIBCXX_DEBUG mode which is making use of the code in 
helper_functions.h.

Clearly this usage of std::__is_void could be replaced with your builtin 
by reimplementing _Distance_traits like this:

   template<typename _Iterator,
        typename = typename std::__is_integer<_Iterator>::__type>
     struct _Distance_traits
     {
     private:
       typedef
     typename std::iterator_traits<_Iterator>::difference_type _ItDiffType;

       typedef
     typename std::conditional<__is_void<_ItDiffType>,
                   std::ptrdiff_t, _ItDiffType>::type _DiffType;

     public:
       typedef std::pair<_DiffType, _Distance_precision> __type;
     };

this is untested, just to give you an idea of what your patch could be.

François

Re: [GSoC] Conflicted Built-in Trait Name

[Ken Matsui]

On Mon, Mar 27, 2023 at 10:33 AM François Dumont <frs.dumont@gmail.com> wrote:
>
>
> On 26/03/2023 04:01, Ken Matsui via Libstdc++ wrote:
> > On Sat, Mar 25, 2023 at 5:38 AM Marc Glisse <marc.glisse@inria.fr> wrote:
> >> On Sat, 25 Mar 2023, Ken Matsui via Gcc wrote:
> >>
> >>> 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
> >> This is a testcase, you can rename __is_void to whatever in there, it
> >> doesn't matter.
> >>
> >>> * libstdc++-v3/include/bits/cpp_type_traits.h
> >> This __is_void seems to be used in a single place in
> >> include/debug/helper_functions.h, couldn't we tweak that code so __is_void
> >> becomes unused and can be removed?
> > That worked. Thank you!
> What worked ?

If you meant about the code, I sent a patch series, as you can see in
the following link.

https://gcc.gnu.org/pipermail/gcc-patches/2023-March/614620.html

* In the following patch, I replaced __is_void with std::is_void in
helper_functions.h.
  https://gcc.gnu.org/pipermail/gcc-patches/2023-March/614624.html
* And then, I deleted __is_void in cpp_type_traits.h.
  https://gcc.gnu.org/pipermail/gcc-patches/2023-March/614623.html
* Also, I replaced __is_void with ____is_void in the testcase.
  https://gcc.gnu.org/pipermail/gcc-patches/2023-March/614625.html

If you meant what tests had been done, I did the following tests
because the header is under libstdc++.

* make check-gcc-c++ (because the patches involve changes on GCC)
* make check-target-libstdc++-v3

> > So, we can remove a code in a header as long as it is not standard and
> > is not used elsewhere, can't we?
>
> You can do anything you like as long as you run the testsuite before
> presenting your patch. Here note that you'll need to run:
>
> make check-debug
>
> to run tests in _GLIBCXX_DEBUG mode which is making use of the code in
> helper_functions.h.
>
> Clearly this usage of std::__is_void could be replaced with your builtin
> by reimplementing _Distance_traits like this:
>
>    template<typename _Iterator,
>         typename = typename std::__is_integer<_Iterator>::__type>
>      struct _Distance_traits
>      {
>      private:
>        typedef
>      typename std::iterator_traits<_Iterator>::difference_type _ItDiffType;
>
>        typedef
>      typename std::conditional<__is_void<_ItDiffType>,
>                    std::ptrdiff_t, _ItDiffType>::type _DiffType;
>
>      public:
>        typedef std::pair<_DiffType, _Distance_precision> __type;
>      };
>
> this is untested, just to give you an idea of what your patch could be.
>
> François

Thank you! I thought the tests that I did included the
hepler_function.h header, but they don’t...? If not, I must check if
std::is_void in the type_traits header was correctly used.

Re: [GSoC] Conflicted Built-in Trait Name

[Jonathan Wakely]

On Mon, 27 Mar 2023 at 21:17, Ken Matsui via Libstdc++
<libstdc++@gcc.gnu.org> wrote:
>
> On Mon, Mar 27, 2023 at 10:33 AM François Dumont <frs.dumont@gmail.com> wrote:
> >
> >
> > On 26/03/2023 04:01, Ken Matsui via Libstdc++ wrote:
> > > On Sat, Mar 25, 2023 at 5:38 AM Marc Glisse <marc.glisse@inria.fr> wrote:
> > >> On Sat, 25 Mar 2023, Ken Matsui via Gcc wrote:
> > >>
> > >>> 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
> > >> This is a testcase, you can rename __is_void to whatever in there, it
> > >> doesn't matter.
> > >>
> > >>> * libstdc++-v3/include/bits/cpp_type_traits.h
> > >> This __is_void seems to be used in a single place in
> > >> include/debug/helper_functions.h, couldn't we tweak that code so __is_void
> > >> becomes unused and can be removed?
> > > That worked. Thank you!
> > What worked ?
>
> If you meant about the code, I sent a patch series, as you can see in
> the following link.
>
> https://gcc.gnu.org/pipermail/gcc-patches/2023-March/614620.html
>
> * In the following patch, I replaced __is_void with std::is_void in
> helper_functions.h.

You can't do that. std::is_void is not present in C++98 mode, but the
code in <debug/helper_functions.h> needs to work for C++98 mode.

>   https://gcc.gnu.org/pipermail/gcc-patches/2023-March/614624.html
> * And then, I deleted __is_void in cpp_type_traits.h.
>   https://gcc.gnu.org/pipermail/gcc-patches/2023-March/614623.html
> * Also, I replaced __is_void with ____is_void in the testcase.
>   https://gcc.gnu.org/pipermail/gcc-patches/2023-March/614625.html
>
> If you meant what tests had been done, I did the following tests
> because the header is under libstdc++.
>
> * make check-gcc-c++ (because the patches involve changes on GCC)
> * make check-target-libstdc++-v3
>
> > > So, we can remove a code in a header as long as it is not standard and
> > > is not used elsewhere, can't we?
> >
> > You can do anything you like as long as you run the testsuite before
> > presenting your patch. Here note that you'll need to run:
> >
> > make check-debug
> >
> > to run tests in _GLIBCXX_DEBUG mode which is making use of the code in
> > helper_functions.h.
> >
> > Clearly this usage of std::__is_void could be replaced with your builtin
> > by reimplementing _Distance_traits like this:
> >
> >    template<typename _Iterator,
> >         typename = typename std::__is_integer<_Iterator>::__type>
> >      struct _Distance_traits
> >      {
> >      private:
> >        typedef
> >      typename std::iterator_traits<_Iterator>::difference_type _ItDiffType;
> >
> >        typedef
> >      typename std::conditional<__is_void<_ItDiffType>,
> >                    std::ptrdiff_t, _ItDiffType>::type _DiffType;
> >
> >      public:
> >        typedef std::pair<_DiffType, _Distance_precision> __type;
> >      };
> >
> > this is untested, just to give you an idea of what your patch could be.
> >
> > François
>
> Thank you! I thought the tests that I did included the
> hepler_function.h header, but they don’t...? If not, I must check if
> std::is_void in the type_traits header was correctly used.

Re: [GSoC] Conflicted Built-in Trait Name

[Jonathan Wakely]

On Mon, 27 Mar 2023 at 22:43, Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
>
> On Mon, 27 Mar 2023 at 21:17, Ken Matsui via Libstdc++
> <libstdc++@gcc.gnu.org> wrote:
> >
> > On Mon, Mar 27, 2023 at 10:33 AM François Dumont <frs.dumont@gmail.com> wrote:
> > >
> > >
> > > On 26/03/2023 04:01, Ken Matsui via Libstdc++ wrote:
> > > > On Sat, Mar 25, 2023 at 5:38 AM Marc Glisse <marc.glisse@inria.fr> wrote:
> > > >> On Sat, 25 Mar 2023, Ken Matsui via Gcc wrote:
> > > >>
> > > >>> 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
> > > >> This is a testcase, you can rename __is_void to whatever in there, it
> > > >> doesn't matter.
> > > >>
> > > >>> * libstdc++-v3/include/bits/cpp_type_traits.h
> > > >> This __is_void seems to be used in a single place in
> > > >> include/debug/helper_functions.h, couldn't we tweak that code so __is_void
> > > >> becomes unused and can be removed?
> > > > That worked. Thank you!
> > > What worked ?
> >
> > If you meant about the code, I sent a patch series, as you can see in
> > the following link.
> >
> > https://gcc.gnu.org/pipermail/gcc-patches/2023-March/614620.html
> >
> > * In the following patch, I replaced __is_void with std::is_void in
> > helper_functions.h.
>
> You can't do that. std::is_void is not present in C++98 mode, but the
> code in <debug/helper_functions.h> needs to work for C++98 mode.
>
> >   https://gcc.gnu.org/pipermail/gcc-patches/2023-March/614624.html
> > * And then, I deleted __is_void in cpp_type_traits.h.
> >   https://gcc.gnu.org/pipermail/gcc-patches/2023-March/614623.html
> > * Also, I replaced __is_void with ____is_void in the testcase.
> >   https://gcc.gnu.org/pipermail/gcc-patches/2023-March/614625.html
> >
> > If you meant what tests had been done, I did the following tests
> > because the header is under libstdc++.
> >
> > * make check-gcc-c++ (because the patches involve changes on GCC)
> > * make check-target-libstdc++-v3
> >
> > > > So, we can remove a code in a header as long as it is not standard and
> > > > is not used elsewhere, can't we?
> > >
> > > You can do anything you like as long as you run the testsuite before
> > > presenting your patch. Here note that you'll need to run:
> > >
> > > make check-debug
> > >
> > > to run tests in _GLIBCXX_DEBUG mode which is making use of the code in
> > > helper_functions.h.
> > >
> > > Clearly this usage of std::__is_void could be replaced with your builtin
> > > by reimplementing _Distance_traits like this:
> > >
> > >    template<typename _Iterator,
> > >         typename = typename std::__is_integer<_Iterator>::__type>
> > >      struct _Distance_traits
> > >      {
> > >      private:
> > >        typedef
> > >      typename std::iterator_traits<_Iterator>::difference_type _ItDiffType;
> > >
> > >        typedef
> > >      typename std::conditional<__is_void<_ItDiffType>,
> > >                    std::ptrdiff_t, _ItDiffType>::type _DiffType;
> > >
> > >      public:
> > >        typedef std::pair<_DiffType, _Distance_precision> __type;
> > >      };
> > >
> > > this is untested, just to give you an idea of what your patch could be.
> > >
> > > François
> >
> > Thank you! I thought the tests that I did included the
> > hepler_function.h header, but they don’t...? If not, I must check if
> > std::is_void in the type_traits header was correctly used.

Something like this would work:

--- a/libstdc++-v3/include/debug/helper_functions.h
+++ b/libstdc++-v3/include/debug/helper_functions.h
@@ -66,13 +66,12 @@ namespace __gnu_debug
      typedef
       typename std::iterator_traits<_Iterator>::difference_type _ItDiffType;

-      template<typename _DiffType,
-              typename = typename std::__is_void<_DiffType>::__type>
+      template<typename _DiffType, typename = const _DiffType>
       struct _DiffTraits
       { typedef _DiffType __type; };

      template<typename _DiffType>
-       struct _DiffTraits<_DiffType, std::__true_type>
+       struct _DiffTraits<_DiffType, const void>
       { typedef std::ptrdiff_t __type; };

      typedef typename _DiffTraits<_ItDiffType>::__type _DiffType;

Re: [GSoC] Conflicted Built-in Trait Name

[Ken Matsui]

Oh! Thank you!

On Mon, Mar 27, 2023 at 2:49 PM Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
>
> On Mon, 27 Mar 2023 at 22:43, Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
> >
> > On Mon, 27 Mar 2023 at 21:17, Ken Matsui via Libstdc++
> > <libstdc++@gcc.gnu.org> wrote:
> > >
> > > On Mon, Mar 27, 2023 at 10:33 AM François Dumont <frs.dumont@gmail.com> wrote:
> > > >
> > > >
> > > > On 26/03/2023 04:01, Ken Matsui via Libstdc++ wrote:
> > > > > On Sat, Mar 25, 2023 at 5:38 AM Marc Glisse <marc.glisse@inria.fr> wrote:
> > > > >> On Sat, 25 Mar 2023, Ken Matsui via Gcc wrote:
> > > > >>
> > > > >>> 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
> > > > >> This is a testcase, you can rename __is_void to whatever in there, it
> > > > >> doesn't matter.
> > > > >>
> > > > >>> * libstdc++-v3/include/bits/cpp_type_traits.h
> > > > >> This __is_void seems to be used in a single place in
> > > > >> include/debug/helper_functions.h, couldn't we tweak that code so __is_void
> > > > >> becomes unused and can be removed?
> > > > > That worked. Thank you!
> > > > What worked ?
> > >
> > > If you meant about the code, I sent a patch series, as you can see in
> > > the following link.
> > >
> > > https://gcc.gnu.org/pipermail/gcc-patches/2023-March/614620.html
> > >
> > > * In the following patch, I replaced __is_void with std::is_void in
> > > helper_functions.h.
> >
> > You can't do that. std::is_void is not present in C++98 mode, but the
> > code in <debug/helper_functions.h> needs to work for C++98 mode.
> >
> > >   https://gcc.gnu.org/pipermail/gcc-patches/2023-March/614624.html
> > > * And then, I deleted __is_void in cpp_type_traits.h.
> > >   https://gcc.gnu.org/pipermail/gcc-patches/2023-March/614623.html
> > > * Also, I replaced __is_void with ____is_void in the testcase.
> > >   https://gcc.gnu.org/pipermail/gcc-patches/2023-March/614625.html
> > >
> > > If you meant what tests had been done, I did the following tests
> > > because the header is under libstdc++.
> > >
> > > * make check-gcc-c++ (because the patches involve changes on GCC)
> > > * make check-target-libstdc++-v3
> > >
> > > > > So, we can remove a code in a header as long as it is not standard and
> > > > > is not used elsewhere, can't we?
> > > >
> > > > You can do anything you like as long as you run the testsuite before
> > > > presenting your patch. Here note that you'll need to run:
> > > >
> > > > make check-debug
> > > >
> > > > to run tests in _GLIBCXX_DEBUG mode which is making use of the code in
> > > > helper_functions.h.
> > > >
> > > > Clearly this usage of std::__is_void could be replaced with your builtin
> > > > by reimplementing _Distance_traits like this:
> > > >
> > > >    template<typename _Iterator,
> > > >         typename = typename std::__is_integer<_Iterator>::__type>
> > > >      struct _Distance_traits
> > > >      {
> > > >      private:
> > > >        typedef
> > > >      typename std::iterator_traits<_Iterator>::difference_type _ItDiffType;
> > > >
> > > >        typedef
> > > >      typename std::conditional<__is_void<_ItDiffType>,
> > > >                    std::ptrdiff_t, _ItDiffType>::type _DiffType;
> > > >
> > > >      public:
> > > >        typedef std::pair<_DiffType, _Distance_precision> __type;
> > > >      };
> > > >
> > > > this is untested, just to give you an idea of what your patch could be.
> > > >
> > > > François
> > >
> > > Thank you! I thought the tests that I did included the
> > > hepler_function.h header, but they don’t...? If not, I must check if
> > > std::is_void in the type_traits header was correctly used.
>
> Something like this would work:
>
> --- a/libstdc++-v3/include/debug/helper_functions.h
> +++ b/libstdc++-v3/include/debug/helper_functions.h
> @@ -66,13 +66,12 @@ namespace __gnu_debug
>       typedef
>        typename std::iterator_traits<_Iterator>::difference_type _ItDiffType;
>
> -      template<typename _DiffType,
> -              typename = typename std::__is_void<_DiffType>::__type>
> +      template<typename _DiffType, typename = const _DiffType>
>        struct _DiffTraits
>        { typedef _DiffType __type; };
>
>       template<typename _DiffType>
> -       struct _DiffTraits<_DiffType, std::__true_type>
> +       struct _DiffTraits<_DiffType, const void>
>        { typedef std::ptrdiff_t __type; };
>
>       typedef typename _DiffTraits<_ItDiffType>::__type _DiffType;

Re: [GSoC] Conflicted Built-in Trait Name

[Jonathan Wakely]

On Sat, 25 Mar 2023 at 12:23, Roy Jacobson via Libstdc++
<libstdc++@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
> >
>

Re: [GSoC] Conflicted Built-in Trait Name

[Ken Matsui]

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

On Mon, Mar 27, 2023 at 2:59 PM Jonathan Wakely <jwakely@redhat.com> wrote:
>
> On Sat, 25 Mar 2023 at 12:23, Roy Jacobson via Libstdc++
> <libstdc++@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
> > >
> >
>

Re: [GSoC] Conflicted Built-in Trait Name

[Ken Matsui]

Hi François,

I tried to use `make check-debug`, but my Makefile does not include
the target. Could you please tell me how you generated your Makefile?

FYI, I did this command: `../configure --enable-languages=c++
--disable-error --disable-bootstrap`.

Sincerely,
Ken Matsui

On Mon, Mar 27, 2023 at 10:33 AM François Dumont <frs.dumont@gmail.com> wrote:
>
>
> On 26/03/2023 04:01, Ken Matsui via Libstdc++ wrote:
> > On Sat, Mar 25, 2023 at 5:38 AM Marc Glisse <marc.glisse@inria.fr> wrote:
> >> On Sat, 25 Mar 2023, Ken Matsui via Gcc wrote:
> >>
> >>> 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
> >> This is a testcase, you can rename __is_void to whatever in there, it
> >> doesn't matter.
> >>
> >>> * libstdc++-v3/include/bits/cpp_type_traits.h
> >> This __is_void seems to be used in a single place in
> >> include/debug/helper_functions.h, couldn't we tweak that code so __is_void
> >> becomes unused and can be removed?
> > That worked. Thank you!
> What worked ?
> >
> > So, we can remove a code in a header as long as it is not standard and
> > is not used elsewhere, can't we?
>
> You can do anything you like as long as you run the testsuite before
> presenting your patch. Here note that you'll need to run:
>
> make check-debug
>
> to run tests in _GLIBCXX_DEBUG mode which is making use of the code in
> helper_functions.h.
>
> Clearly this usage of std::__is_void could be replaced with your builtin
> by reimplementing _Distance_traits like this:
>
>    template<typename _Iterator,
>         typename = typename std::__is_integer<_Iterator>::__type>
>      struct _Distance_traits
>      {
>      private:
>        typedef
>      typename std::iterator_traits<_Iterator>::difference_type _ItDiffType;
>
>        typedef
>      typename std::conditional<__is_void<_ItDiffType>,
>                    std::ptrdiff_t, _ItDiffType>::type _DiffType;
>
>      public:
>        typedef std::pair<_DiffType, _Distance_precision> __type;
>      };
>
> this is untested, just to give you an idea of what your patch could be.
>
> François
>
>

Re: [GSoC] Conflicted Built-in Trait Name

[Jonathan Wakely]

On Tue, 28 Mar 2023 at 22:30, Ken Matsui via Libstdc++
<libstdc++@gcc.gnu.org> wrote:
>
> Hi François,
>
> I tried to use `make check-debug`, but my Makefile does not include
> the target. Could you please tell me how you generated your Makefile?

It's a target in the libstdc++ makefile, so you need to run it from
the $target/libstdc++-v3 directory.

Re: [GSoC] Conflicted Built-in Trait Name

[Ken Matsui]

Oooh, thank you for your help!

On Tue, Mar 28, 2023 at 4:25 PM Jonathan Wakely <jwakely@redhat.com> wrote:
>
> On Tue, 28 Mar 2023 at 22:30, Ken Matsui via Libstdc++
> <libstdc++@gcc.gnu.org> wrote:
> >
> > Hi François,
> >
> > I tried to use `make check-debug`, but my Makefile does not include
> > the target. Could you please tell me how you generated your Makefile?
>
> It's a target in the libstdc++ makefile, so you need to run it from
> the $target/libstdc++-v3 directory.
>

Re: [GSoC] Conflicted Built-in Trait Name

[François Dumont]

Hi

Do not hesitate to dig into library doc. Especially this page:

https://gcc.gnu.org/onlinedocs/gcc-8.1.0/libstdc++/manual/manual/test.html

You can also find it in your git clone in <gcc-repo>/libstdc++-v3/doc/html.

You'll see also how to run test in different std modes like --std=c++98 
to catch the kind of issue reported by Jonathan.

Regarding your patches I wonder if it's not too splitted. 1 patch per 
builtin would sound more logical, at least for an easy one like __is_void.

François


On 29/03/2023 01:33, Ken Matsui wrote:
> Oooh, thank you for your help!
>
> On Tue, Mar 28, 2023 at 4:25 PM Jonathan Wakely <jwakely@redhat.com> wrote:
>> On Tue, 28 Mar 2023 at 22:30, Ken Matsui via Libstdc++
>> <libstdc++@gcc.gnu.org> wrote:
>>> Hi François,
>>>
>>> I tried to use `make check-debug`, but my Makefile does not include
>>> the target. Could you please tell me how you generated your Makefile?
>> It's a target in the libstdc++ makefile, so you need to run it from
>> the $target/libstdc++-v3 directory.
>>

Re: [GSoC] Conflicted Built-in Trait Name

[Ken Matsui]

Hi François,

On Wed, Mar 29, 2023 at 10:11 PM François Dumont <frs.dumont@gmail.com> wrote:
>
> Hi
>
> Do not hesitate to dig into library doc. Especially this page:
>
> https://gcc.gnu.org/onlinedocs/gcc-8.1.0/libstdc++/manual/manual/test.html
>
> You can also find it in your git clone in <gcc-repo>/libstdc++-v3/doc/html.
>
> You'll see also how to run test in different std modes like --std=c++98
> to catch the kind of issue reported by Jonathan.

This is what I wanted to know! Thank you so much!

> Regarding your patches I wonder if it's not too splitted. 1 patch per
> builtin would sound more logical, at least for an easy one like __is_void.

I see. I will squash is_void-related commits into the commit of
__is_void implementation. Thank you for pointing it out!

Sincerely,
Ken Matsui

Re: [GSoC] Conflicted Built-in Trait Name

[Jonathan Wakely]

On Thu, 30 Mar 2023 at 09:33, Ken Matsui wrote:
>
> Hi François,
>
> On Wed, Mar 29, 2023 at 10:11 PM François Dumont <frs.dumont@gmail.com> wrote:
> >
> > Hi
> >
> > Do not hesitate to dig into library doc. Especially this page:
> >
> > https://gcc.gnu.org/onlinedocs/gcc-8.1.0/libstdc++/manual/manual/test.html
> >
> > You can also find it in your git clone in <gcc-repo>/libstdc++-v3/doc/html.
> >
> > You'll see also how to run test in different std modes like --std=c++98
> > to catch the kind of issue reported by Jonathan.
>
> This is what I wanted to know! Thank you so much!
>
> > Regarding your patches I wonder if it's not too splitted. 1 patch per
> > builtin would sound more logical, at least for an easy one like __is_void.
>
> I see. I will squash is_void-related commits into the commit of
> __is_void implementation. Thank you for pointing it out!


Yes, good point, François. These kind of changes for the front-end and
library should be in one patch. Otherwise, if they were committed
separately then you would create a revision where bootstrap fails. If
the front-end change is committed without the library change, then you
can't build the library because it still uses __is_void which is now a
keyword. If the library change is committed first then you don't break
bootstrap, but you're adding support to the library for a new built-in
which doesn't actually exist (yet). They should be a single revision,
so that the tree can always be built.

Re: [GSoC] Conflicted Built-in Trait Name

[Ken Matsui]

I see. Thank you for the clarification!

On Thu, Mar 30, 2023 at 5:23 AM Jonathan Wakely <jwakely@redhat.com> wrote:
>
> On Thu, 30 Mar 2023 at 09:33, Ken Matsui wrote:
> >
> > Hi François,
> >
> > On Wed, Mar 29, 2023 at 10:11 PM François Dumont <frs.dumont@gmail.com> wrote:
> > >
> > > Hi
> > >
> > > Do not hesitate to dig into library doc. Especially this page:
> > >
> > > https://gcc.gnu.org/onlinedocs/gcc-8.1.0/libstdc++/manual/manual/test.html
> > >
> > > You can also find it in your git clone in <gcc-repo>/libstdc++-v3/doc/html.
> > >
> > > You'll see also how to run test in different std modes like --std=c++98
> > > to catch the kind of issue reported by Jonathan.
> >
> > This is what I wanted to know! Thank you so much!
> >
> > > Regarding your patches I wonder if it's not too splitted. 1 patch per
> > > builtin would sound more logical, at least for an easy one like __is_void.
> >
> > I see. I will squash is_void-related commits into the commit of
> > __is_void implementation. Thank you for pointing it out!
>
>
> Yes, good point, François. These kind of changes for the front-end and
> library should be in one patch. Otherwise, if they were committed
> separately then you would create a revision where bootstrap fails. If
> the front-end change is committed without the library change, then you
> can't build the library because it still uses __is_void which is now a
> keyword. If the library change is committed first then you don't break
> bootstrap, but you're adding support to the library for a new built-in
> which doesn't actually exist (yet). They should be a single revision,
> so that the tree can always be built.
>