Problem with variadic BOOST_PP_TUPLE_REM in Clang
When using Clang version "Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn)" in C++11 mode, the code: #include <boost/preprocessor.hpp> BOOST_PP_TUPLE_REM()(foo(bar, baz) const) is not expanded correctly. The second line expands to: BOOST_PP_TUPLE_REM_(foo(bar, baz) const) while on GCC 4.9, it expands to: foo(bar, baz) const Is there a known issue with this macro on Clang? -- Jeremiah Willcock
On Nov 13, 2013, at 1:28 PM, Jeremiah Willcock <jewillco@crest.iu.edu> wrote:
When using Clang version "Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn)" in C++11 mode, the code:
#include <boost/preprocessor.hpp> BOOST_PP_TUPLE_REM()(foo(bar, baz) const)
is not expanded correctly. The second line expands to:
BOOST_PP_TUPLE_REM_(foo(bar, baz) const)
while on GCC 4.9, it expands to:
foo(bar, baz) const
Is there a known issue with this macro on Clang?
I see this on clang in both C++03 and C++11 modes. And with gcc 4.7.2, in c++03 mode, for that matter. -- Marshall Marshall Clow Idio Software <mailto:mclow.lists@gmail.com> A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait). -- Yu Suzuki
On 11/13/2013 4:28 PM, Jeremiah Willcock wrote:
When using Clang version "Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn)" in C++11 mode, the code:
#include <boost/preprocessor.hpp> BOOST_PP_TUPLE_REM()(foo(bar, baz) const)
is not expanded correctly. The second line expands to:
BOOST_PP_TUPLE_REM_(foo(bar, baz) const)
while on GCC 4.9, it expands to:
foo(bar, baz) const
Is there a known issue with this macro on Clang?
When Paul created the code for automatically determining if a compiler has variadic macro support he did not include clang as among the compilers for which BOOST_PP_VARIADICS is 1 ( variadic support is on ). Please try specifically turning on variadic macro support for clang by defining BOOST_PP_VARIADICS=1 when you use the clang compiler.
On Wed, Nov 13, 2013 at 8:41 PM, Edward Diener <eldiener@tropicsoft.com>wrote:
When Paul created the code for automatically determining if a compiler has variadic macro support he did not include clang as among the compilers for which BOOST_PP_VARIADICS is 1 ( variadic support is on ). Please try specifically turning on variadic macro support for clang by defining BOOST_PP_VARIADICS=1 when you use the clang compiler.
Shouldn't this branching be inverted now that variadic macros are standard? In other words, shouldn't it rely on BOOST_NO_CXX11_VARIADIC_MACROS? -- -Matt Calabrese
On 11/14/2013 1:16 AM, Matt Calabrese wrote:
On Wed, Nov 13, 2013 at 8:41 PM, Edward Diener <eldiener@tropicsoft.com <mailto:eldiener@tropicsoft.com>> wrote:
When Paul created the code for automatically determining if a compiler has variadic macro support he did not include clang as among the compilers for which BOOST_PP_VARIADICS is 1 ( variadic support is on ). Please try specifically turning on variadic macro support for clang by defining BOOST_PP_VARIADICS=1 when you use the clang compiler.
Shouldn't this branching be inverted now that variadic macros are standard? In other words, shouldn't it rely on BOOST_NO_CXX11_VARIADIC_MACROS?
Currently Boost PP does not depend on any other Boost library, not even Config. I imagine that Paul might respond to this issue. If he does not I will notify him of it.
On Thu, Nov 14, 2013 at 5:26 AM, Edward Diener <eldiener@tropicsoft.com>wrote:
Currently Boost PP does not depend on any other Boost library, not even Config.
I imagine that Paul might respond to this issue. If he does not I will notify him of it.
Regardless, since both C99+ and C++11+ have variadic macros, it should probably be updated to a new BOOST_PP_NO_VARIADICS macro so that we assume compliance by default. -- -Matt Calabrese
On 11/14/2013 5:40 PM, Matt Calabrese wrote:
On Thu, Nov 14, 2013 at 5:26 AM, Edward Diener <eldiener@tropicsoft.com <mailto:eldiener@tropicsoft.com>> wrote:
Currently Boost PP does not depend on any other Boost library, not even Config.
I imagine that Paul might respond to this issue. If he does not I will notify him of it.
Regardless, since both C99+ and C++11+ have variadic macros, it should probably be updated to a new BOOST_PP_NO_VARIADICS macro so that we assume compliance by default.
I think that adding another macro confuses the issue even if it mimics the style of config macros. It is not my call to change the code for determining what compiler should automatically have variadic support enabled in Boost PP, even if I worked prettily heavily on variadic macro support in general in Boost PP with Paul. It's still his library to decide on this IMO and, even though the change is fairly trivial in a single header file, I feel on principal he has to agree to it. I will point this thread out to him. The end-user can always currently set BOOST_PP_VARIADICS to 1 for any compiler to override the Boost PP automatic setting for that particular compiler, but I do understand your feeling that nearly all compilers now support variadic macros so it should be on, unless set off.
On Thu, 14 Nov 2013 18:59:39 -0500, Edward Diener wrote:
On 11/14/2013 5:40 PM, Matt Calabrese wrote:
On Thu, Nov 14, 2013 at 5:26 AM, Edward Diener <eldiener@tropicsoft.com <mailto:eldiener@tropicsoft.com>> wrote:
Currently Boost PP does not depend on any other Boost library, not even Config.
I imagine that Paul might respond to this issue. If he does not I will notify him of it.
Regardless, since both C99+ and C++11+ have variadic macros, it should probably be updated to a new BOOST_PP_NO_VARIADICS macro so that we assume compliance by default.
I think that adding another macro confuses the issue even if it mimics the style of config macros.
It is not my call to change the code for determining what compiler should automatically have variadic support enabled in Boost PP, even if I worked prettily heavily on variadic macro support in general in Boost PP with Paul. It's still his library to decide on this IMO and, even though the change is fairly trivial in a single header file, I feel on principal he has to agree to it. I will point this thread out to him.
The end-user can always currently set BOOST_PP_VARIADICS to 1 for any compiler to override the Boost PP automatic setting for that particular compiler, but I do understand your feeling that nearly all compilers now support variadic macros so it should be on, unless set off.
The basic problem here is that BOOST_PP_VARIADICS is a lot stronger than just "compiler supports variadic macros in some form". The pp-lib doesn't pull Boost.Config for two main reasons. First, Boost.Config's variadic macros support macro is much weaker than what is required by a preprocessor metaprogramming library. Second, unlike the rest of Boost, the pp-lib is used outside of just C++ contexts--in real code in the real world. I.e. it is a C/C++ library, so it cannot pull in code assumed to target C++ only. Even if this is not the case with current Boost.Config, the pp-lib cannot place this restriction on Boost.Config (and vice versa). I just checked and the showstopper bug in clang has apparently been fixed. However, I have not personally confirmed this. Can someone that has a current clang build confirm? http://llvm.org/bugs/show_bug.cgi?id=12767 Otherwise, if everything is working properly as far as we can tell, I have no issue with enabling by default on clang. Regarding the pp-lib in general... it is legacy code that is fundamentally gimped by several preprocessors--notably msvc. If all of the preprocessors were good, the entire library would be different--i.e. it would be more like chaos-pp. Perhaps after this git modularization stuff, chaos-pp goes into Boost (though I personally think that git is an abomination and I'm not at all certain about what "Boost" will even mean at that time). It is also possible that MS makes good on their promise to fix their preprocessor, but I'll believe that when I see it (and then look for ulterior motives). Otherwise, for code outside of Boost, if you only have to target non-crap compilers, use chaos-pp. It is a far superior library distributed under the same license. Regards, Paul Mensonides
On 11/20/2013 8:39 AM, Paul Mensonides wrote:
On Thu, 14 Nov 2013 18:59:39 -0500, Edward Diener wrote:
On 11/14/2013 5:40 PM, Matt Calabrese wrote:
On Thu, Nov 14, 2013 at 5:26 AM, Edward Diener <eldiener@tropicsoft.com <mailto:eldiener@tropicsoft.com>> wrote:
Currently Boost PP does not depend on any other Boost library, not even Config.
I imagine that Paul might respond to this issue. If he does not I will notify him of it.
Regardless, since both C99+ and C++11+ have variadic macros, it should probably be updated to a new BOOST_PP_NO_VARIADICS macro so that we assume compliance by default.
I think that adding another macro confuses the issue even if it mimics the style of config macros.
It is not my call to change the code for determining what compiler should automatically have variadic support enabled in Boost PP, even if I worked prettily heavily on variadic macro support in general in Boost PP with Paul. It's still his library to decide on this IMO and, even though the change is fairly trivial in a single header file, I feel on principal he has to agree to it. I will point this thread out to him.
The end-user can always currently set BOOST_PP_VARIADICS to 1 for any compiler to override the Boost PP automatic setting for that particular compiler, but I do understand your feeling that nearly all compilers now support variadic macros so it should be on, unless set off.
The basic problem here is that BOOST_PP_VARIADICS is a lot stronger than just "compiler supports variadic macros in some form". The pp-lib doesn't pull Boost.Config for two main reasons. First, Boost.Config's variadic macros support macro is much weaker than what is required by a preprocessor metaprogramming library. Second, unlike the rest of Boost, the pp-lib is used outside of just C++ contexts--in real code in the real world. I.e. it is a C/C++ library, so it cannot pull in code assumed to target C++ only. Even if this is not the case with current Boost.Config, the pp-lib cannot place this restriction on Boost.Config (and vice versa).
I just checked and the showstopper bug in clang has apparently been fixed. However, I have not personally confirmed this. Can someone that has a current clang build confirm?
The bug does not occur in the current clang build, so it is fixed in my test.
Otherwise, if everything is working properly as far as we can tell, I have no issue with enabling by default on clang.
I can do this on 'trunk'. I have been working with clang in testing Boost PP, while also updating some of the Boost PP tests, and it is passing all tests.
Regarding the pp-lib in general... it is legacy code that is fundamentally gimped by several preprocessors--notably msvc. If all of the preprocessors were good, the entire library would be different--i.e. it would be more like chaos-pp. Perhaps after this git modularization stuff, chaos-pp goes into Boost (though I personally think that git is an abomination and I'm not at all certain about what "Boost" will even mean at that time).
I encourage you to submit chaos-pp for inclusion into Boost. I see no reason why a library, without any compiler workarounds, cannot be part of Boost even if it does not work on all compilers because of some deficiency(s) in particular compilers.
It is also possible that MS makes good on their promise to fix their preprocessor, but I'll believe that when I see it (and then look for ulterior motives).
I have not tested VC++12, but nothing in the online description of its fixes suggest that the VC++ preprocessor has been fixed yet. If chaos-pp were part of Boost it would also be an excellent way to determine if the VC++ preprocessor has been fixed at some future point in time.
Otherwise, for code outside of Boost, if you only have to target non-crap compilers, use chaos-pp. It is a far superior library distributed under the same license.
On Wed, Nov 20, 2013 at 8:36 AM, Edward Diener <eldiener@tropicsoft.com>wrote:
I encourage you to submit chaos-pp for inclusion into Boost. I see no reason why a library, without any compiler workarounds, cannot be part of Boost even if it does not work on all compilers because of some deficiency(s) in particular compilers.
+1 I know we've been having this discussion for many years, but every single time it comes up, I don't think there's really been any disagreement.
I have not tested VC++12, but nothing in the online description of its fixes suggest that the VC++ preprocessor has been fixed yet. If chaos-pp were part of Boost it would also be an excellent way to determine if the VC++ preprocessor has been fixed at some future point in time.
Also, if more boost libraries use chaos as opposed to boost preprocessor and we simply refuse to do any major workarounds, it puts a lot more pressure on Microsoft to fix their preprocessor, though at this point I doubt it really will get fixed, at least not for a long while still. -- -Matt Calabrese
On Wed, 20 Nov 2013 05:39:13 -0800, Paul Mensonides <pmenso57@comcast.net> wrote:
[snip]
Second, unlike the rest of Boost, the pp-lib is used outside of just C++ contexts--in real code in the real world. I.e. it is a C/C++ library, so it cannot pull in code assumed to target C++ only. Even if this is not the case with current Boost.Config, the pp-lib cannot place this restriction on Boost.Config (and vice versa).
I did not know that it also officially supported C. I don't believe that this is clearly mentioned in the online documentation. Can this be added to the introduction section? (Yes, the title does say "The Boost Library Preprocessor Subset for C/C++", but I think the C part of C/C++ is too easily overlooked.) Thanks, Mostafa
On 11/20/2013 8:39 AM, Paul Mensonides wrote:
On Thu, 14 Nov 2013 18:59:39 -0500, Edward Diener wrote:
On 11/14/2013 5:40 PM, Matt Calabrese wrote:
On Thu, Nov 14, 2013 at 5:26 AM, Edward Diener <eldiener@tropicsoft.com <mailto:eldiener@tropicsoft.com>> wrote:
Currently Boost PP does not depend on any other Boost library, not even Config.
I imagine that Paul might respond to this issue. If he does not I will notify him of it.
Regardless, since both C99+ and C++11+ have variadic macros, it should probably be updated to a new BOOST_PP_NO_VARIADICS macro so that we assume compliance by default.
I think that adding another macro confuses the issue even if it mimics the style of config macros.
It is not my call to change the code for determining what compiler should automatically have variadic support enabled in Boost PP, even if I worked prettily heavily on variadic macro support in general in Boost PP with Paul. It's still his library to decide on this IMO and, even though the change is fairly trivial in a single header file, I feel on principal he has to agree to it. I will point this thread out to him.
The end-user can always currently set BOOST_PP_VARIADICS to 1 for any compiler to override the Boost PP automatic setting for that particular compiler, but I do understand your feeling that nearly all compilers now support variadic macros so it should be on, unless set off.
The basic problem here is that BOOST_PP_VARIADICS is a lot stronger than just "compiler supports variadic macros in some form". The pp-lib doesn't pull Boost.Config for two main reasons. First, Boost.Config's variadic macros support macro is much weaker than what is required by a preprocessor metaprogramming library. Second, unlike the rest of Boost, the pp-lib is used outside of just C++ contexts--in real code in the real world. I.e. it is a C/C++ library, so it cannot pull in code assumed to target C++ only. Even if this is not the case with current Boost.Config, the pp-lib cannot place this restriction on Boost.Config (and vice versa).
I just checked and the showstopper bug in clang has apparently been fixed. However, I have not personally confirmed this. Can someone that has a current clang build confirm?
http://llvm.org/bugs/show_bug.cgi?id=12767
Otherwise, if everything is working properly as far as we can tell, I have no issue with enabling by default on clang.
I have updated the Boost PP config.h on the 'trunk' so that BOOST_PP_VARIADICS is now enabled for clang by default. I will check any clang regression tests to make sure this does not cause any problems. In my own testing for clang and Boost PP, withe variadic macro support turned on, clang passed all Boost PP tests.
participants (6)
-
Edward Diener -
Jeremiah Willcock -
Marshall Clow -
Matt Calabrese -
Mostafa -
Paul Mensonides