Turn warnings to 'on' for clang to avoid Boost PP warnings. #4
Conversation
|
I appreciate why this patch has been submitted. However, my experience has been that many regex users really do want to be able to compile with -pedantic and if they can't they complain :-( For that reason I would prefer to continue to build and test with all to expose any problems. Is this really unfixable in the preprocessor lib? |
|
Would a pull request with clang having the options '-Wno-c99-extensions' and '-Wno-variadic-macros' turned on, without removing '-pedantic' by keeping the warnings as 'all', in the regex build jamfile be acceptable ? |
|
Good question - my gut feeling is that the status quo represents a common real-world use case that folks expect to see warning free. However, I'll try and fire up Linux and clang later and see how bad things are for myself ;-) |
|
I believe this is best fixed in the preprocessor library, some experimenting suggests that adding: #if defined(clang) && defined(GNUC) To the files emitting the warnings fixes this rather nicely. Alternatively: ifdef clangpragma clang diagnostic pushpragma clang diagnostic ignored "-Wvariadic-macros"endif// variadic macros defined ifdef clangpragma clang diagnostic popendifAlso works and is rather more finely grained in it's control. |
|
Please do not close this until I can respond. I do not believe that declaring all the affected preprocessor headers as system headers is the right solution, even if it might work in practice. Turning off all warnings in those headers for gcc and clang cannot be correct IMO, and who knows what else it means in GCC/clang to pretend that one's header file is a system header file. I really do not want to take that chance. Your secondary solution works with the "-Wvariadic-macros" diagnostic works just fine. But it does not work on clang, although it should, with the "-Wc99-extensions" diagnostic. There is plenty of such verbose output stemming from a single line in variadic/elem.hpp. Yet my attempt to surround that line with: ifdef clangpragma clang diagnostic pushpragma clang diagnostic ignored "-Wc99-extensions"endif// The line etc. ifdef clangpragma clang diagnostic popendiffails to eliminate he warning. This seems like a clang bug. |
|
Edward, there's no good solution here - changing the command line certainly works, but then users will still see the warnings in their own code (including from header only libraries) and no doubt complain. I just don't see this as the right solution. Here's the fix I've just tested with current develop and current clang svn: diff --git a/include/boost/preprocessor/facilities/overload.hpp b/include/boost/preprocessor/facilities/overload.hpp /* BOOST_PP_OVERLOAD _/if BOOST_PP_VARIADICS+# define BOOST_PP_OVERLOAD(prefix, ...) BOOST_PP_CAT(prefix, BOOST_PP_VARIADIC_SIZE(VA_ARGS))+# endifendifdiff --git a/include/boost/preprocessor/tuple/eat.hpp b/include/boost/preprocessor/tuple/eat.hpp /_ BOOST_PP_EAT _/if BOOST_PP_VARIADICS+# define BOOST_PP_EAT(...)+# elsedefine BOOST_PP_EAT(x)endifdiff --git a/include/boost/preprocessor/tuple/elem.hpp b/include/boost/preprocessor/tuple/elem.hpp include <boost/preprocessor/tuple/detail/is_single_return.hpp>if BOOST_PP_VARIADICS+# if BOOST_PP_VARIADICS_MSVCdefine BOOST_PP_TUPLE_ELEM(...) BOOST_PP_TUPLE_ELEM_I(BOOST_PP_OVERLOAD(BOOST_PP_TUPLE_ELEM_O_, VA_ARGS), (VA_ARGS))define BOOST_PP_TUPLE_ELEM_I(m, args) BOOST_PP_TUPLE_ELEM_II(m, args)@@ -41,6 +47,11 @@ define BOOST_PP_TUPLE_ELEM_O_2(n, tuple) BOOST_PP_VARIADIC_ELEM(n, BOOST_PP_REM tuple)endifdefine BOOST_PP_TUPLE_ELEM_O_3(size, n, tuple) BOOST_PP_TUPLE_ELEM_O_2(n, tuple)+# elseif BOOST_PP_CONFIG_FLAGS() & BOOST_PP_CONFIG_MSVC()define BOOST_PP_TUPLE_ELEM(size, n, tuple) BOOST_PP_TUPLE_ELEM_I(BOOST_PP_CAT(BOOST_PP_TUPLE_ELEM_, n), BOOST_PP_CAT(BOOST_PP_CAT(BOOST_PP_TUPLE_ELEM_E_, size), tuple))diff --git a/include/boost/preprocessor/tuple/rem.hpp b/include/boost/preprocessor/tuple/rem.hpp /_ BOOST_PP_REM _/if BOOST_PP_VARIADICS+# if BOOST_PP_VARIADICS_MSVCdefine BOOST_PP_REM_CAT(...) BOOST_PP_CAT(VA_ARGS,)endifdefine BOOST_PP_REM(...) VA_ARGS+# elsedefine BOOST_PP_REM(x) xendif@@ -120,6 +131,12 @@ /_ BOOST_PP_TUPLE_REM_CTOR _/if BOOST_PP_VARIADICS+# if BOOST_PP_VARIADICS_MSVCdefine BOOST_PP_TUPLE_REM_CTOR(...) BOOST_PP_TUPLE_REM_CTOR_I(BOOST_PP_OVERLOAD(BOOST_PP_TUPLE_REM_CTOR_O_, VA_ARGS), (VA_ARGS))define BOOST_PP_TUPLE_REM_CTOR_I(m, args) BOOST_PP_TUPLE_REM_CTOR_II(m, args)@@ -130,6 +147,11 @@ define BOOST_PP_TUPLE_REM_CTOR_O_1(tuple) BOOST_PP_REM tupleendifdefine BOOST_PP_TUPLE_REM_CTOR_O_2(size, tuple) BOOST_PP_TUPLE_REM_CTOR_O_1(tuple)+# elseif ~BOOST_PP_CONFIG_FLAGS() & BOOST_PP_CONFIG_EDG()define BOOST_PP_TUPLE_REM_CTOR(size, tuple) BOOST_PP_TUPLE_REM_CTOR_I(BOOST_PP_TUPLE_REM(size), tuple)diff --git a/include/boost/preprocessor/variadic/elem.hpp b/include/boost/preprocessor/variadic/elem.hpp /_ BOOST_PP_VARIADIC_ELEM _/if BOOST_PP_VARIADICS+# if BOOST_PP_VARIADICS_MSVCdefine BOOST_PP_VARIADIC_ELEM(n, ...) BOOST_PP_VARIADIC_ELEM_I(n,VA_ARGS)define BOOST_PP_VARIADIC_ELEM_I(n, ...) BOOST_PP_CAT(BOOST_PP_CAT(BOOST_PP_VARIADIC_ELEM_, n)(VA_ARGS,),)@@ -91,4 +97,8 @@ define BOOST_PP_VARIADIC_ELEM_63(e0, e1, e2, e3, e4, e5, e6, e7, e8, e9, e10, e11, e12, e13, e14, e15, e16, e17, e18, e19, e20, e21, e22, e23, e24, e25, e26, e27, e28, e29, e30, e31, e32, e33, e34, e35, e36, e37, e38, e39, e40, e41, e42, e43, e44, e45, e46, e47, e48, e49, e50, e51, e52, e53, e54, e55, e56, e57, e58, e59, e60, e61, e62, e63, ...) e63endif+# ifdef clang endifdiff --git a/include/boost/preprocessor/variadic/size.hpp b/include/boost/preprocessor/variadic/size.hpp /_ BOOST_PP_VARIADIC_SIZE */if BOOST_PP_VARIADICS+# if BOOST_PP_VARIADICS_MSVCdefine BOOST_PP_VARIADIC_SIZE(...) BOOST_PP_CAT(BOOST_PP_VARIADIC_SIZE_I(VA_ARGS, 64, 63, 62, 61, 60, 59, 58, 57, 56, 55, 54, 53, 52, 51, 50, 49, 48, 47, 46, 45, 44, 43, 42, 41, 40, 39, 38, 37, 36, 35, 34, 33, 32, 31, 30, 29, 28, 27, 26, 25, 24, 23, 22, 21, 20, 19, 18, 17, 16, 15, 14, 13, 12, 11, 10, 9, 8, 7, 6, 5, 4, 3, 2, 1,),)else@@ -27,4 +33,8 @@ define BOOST_PP_VARIADIC_SIZE_I(e0, e1, e2, e3, e4, e5, e6, e7, e8, e9, e10, e11, e12, e13, e14, e15, e16, e17, e18, e19, e20, e21, e22, e23, e24, e25, e26, e27, e28, e29, e30, e31, e32, e33, e34, e35, e36, e37, e38, e39, e40, e41, e42, e43, e44, e45, e46, e47, e48, e49, e50, e51, e52, e53, e54, e55, e56, e57, e58, e59, e60, e61, e62, e63, size, ...) sizeendif+# ifdef clang endifIn addition a patch to mpl is required: diff --git a/include/boost/mpl/aux_/include_preprocessed.hpp b/include/boost/mpl/aux_/include_preprocessed.hpp include AUX778076_INCLUDE_STRINGundef AUX778076_INCLUDE_STRING#else include BOOST_PP_STRINGIZE(boost/mpl/aux_/preprocessed/AUX778076_PREPROCESSED_HEADER)+# ifdef clang undef AUX778076_PREPROCESSED_HEADERdiff --git a/include/boost/mpl/if.hpp b/include/boost/mpl/if.hpp #endif // BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION +# ifdef clang +# ifdef clang #endif // BOOST_MPL_IF_HPP_INCLUDED +# ifdef clang +# ifdef clang #endif // BOOST_MPL_NOT_HPP_INCLUDED With that regex compiles cleanly without all the warnings. |
|
I am aware of this type of fix. Please see my latest post on the boost developers mailing list. The issue is that while the -Wvariadic-macros warnings can be handled at the Boost PP level, which I also have already done locally, the -Wc99-extensions warnings must be all handled at their point of origin, as you have done above. But as soon as another macro ends up calling the Boost PP macro which causes the -Wc99-extensions warning, that has to be handled at the top-level again. And if other macros are added to Boost PP, or any other macro library, which induce the clang -Wc99-extensions warning, it again has to be handled at the top level as you do above. This does not scale very well as a solution as I am sure you will agree. So while my local Boost PP changes ( mimicking yours above ) solves the -Wvariadic-macros warnings problem, the -Wc99-extensions warning problem will always have to be solved again and again at some top-level macro eventually calling a variadic macro which produces the warning in clang. |
If warnings are 'all' many clang warnings in Boost PP occur.