clang and variadic macro warnings revisited
After making pull requests for a number of Boost libraries in order to reduce the warnings from compilation from clang using the Boost PP library, John Maddock suggested a specific solution, as Niall Douglas had suggested a general one before, that changes in the Boost PP library could get rid of these extraneous warnings. Originally I thought this would be too difficult and intrusive in Boost PP but after reading John's specific suggestion I decided to try to implement it. The suggestion John made was to surround code in Boost PP which uses variadic macros with: # ifdef __clang__ # pragma clang diagnostic push # pragma clang diagnostic ignored "-Wvariadic-macros" # endif // variadic macros # ifdef __clang__ # pragma clang diagnostic pop # endif This was actually easier than expected since all code in Boost PP which uses variadic macros is surrounded by: # if BOOST_PP_VARIADICS #endif // eventually Of course there are many files changed by this but overall it is very straightforward. This technique does work for the diagnostic "-Wvariadic-macros". Hooray ! Unfortunately the second situation involving warnings, where clang warns about: warning: empty macro arguments are a C99 feature [-Wc99-extensions] coming from what I only see as a specific place in Boost PP in variadic/elem.hpp is not conducive to the same technique. In other words surrounding that one macro with: # ifdef __clang__ # pragma clang diagnostic push # pragma clang diagnostic ignored "-Wc99-extensions" # endif #define BOOST_PP_VARIADIC_ELEM(n, ...) BOOST_PP_CAT(BOOST_PP_VARIADIC_ELEM_, n)(__VA_ARGS__,) # ifdef __clang__ # pragma clang diagnostic pop # endif does not eliminate the warning at all ( I have reported this on the clang developers mailing list ). And since that macro is heavily used in Boost PP this warning occurs quite often when compiling Boost library code using Boost PP wih clang. The only other intrusive Boost PP solution to this problem is to treat clang like gcc as far as Boost PP variadic macro code is concerned: if the end-user compiles with one of the 'std=' dialects which explicitly supports variadic macros, such as 'std=c99', 'std=c++0x, 'std=c++11', then variadic macros are turned on in Boost PP for clang, else they are turned off. Do realize that both gcc and clang support variadic macros even when one of the 'std=' dialects are not chosen, and that in fact clang has always supported variadic macros. Also changing Boost PP support for clang and variadic macros would be a regression from the way it is now where it is always supported. In retrospect, when I changed Boost PP from never supporting variadic macros for clang ( Paul's original conservative choice ) to always supporting variadic macros for clang, I gave in to an outcry that clang users should have variadic macro support in Boost PP. It would have been wiser to follow the gcc method in Boost PP. But that is past and we need a good solution now. Thoughts ? Solutions ? Brickbats <g> ?
On Sunday 17 August 2014 13:56:39 Edward Diener wrote:
Unfortunately the second situation involving warnings, where clang warns about:
warning: empty macro arguments are a C99 feature [-Wc99-extensions]
coming from what I only see as a specific place in Boost PP in variadic/elem.hpp is not conducive to the same technique. In other words surrounding that one macro with:
# ifdef __clang__ # pragma clang diagnostic push # pragma clang diagnostic ignored "-Wc99-extensions" # endif
#define BOOST_PP_VARIADIC_ELEM(n, ...) BOOST_PP_CAT(BOOST_PP_VARIADIC_ELEM_, n)(__VA_ARGS__,)
# ifdef __clang__ # pragma clang diagnostic pop # endif
does not eliminate the warning at all ( I have reported this on the clang developers mailing list ). And since that macro is heavily used in Boost PP this warning occurs quite often when compiling Boost library code using Boost PP wih clang.
Are the warnings emitted upon the macro expansion? If so you could try embedding _Pragma into the macro.
The only other intrusive Boost PP solution to this problem is to treat clang like gcc as far as Boost PP variadic macro code is concerned: if the end-user compiles with one of the 'std=' dialects which explicitly supports variadic macros, such as 'std=c99', 'std=c++0x, 'std=c++11', then variadic macros are turned on in Boost PP for clang, else they are turned off. Do realize that both gcc and clang support variadic macros even when one of the 'std=' dialects are not chosen, and that in fact clang has always supported variadic macros. Also changing Boost PP support for clang and variadic macros would be a regression from the way it is now where it is always supported.
IMHO, if nothing helps then it is ok to enable variadic macros only when supported by the standard. That is the only condition we can require from compilers. Other cases are extension, which may not be usable and it's ok if we don't use it when it brings caveats like this.
On 8/17/2014 5:26 PM, Andrey Semashev wrote:
On Sunday 17 August 2014 13:56:39 Edward Diener wrote:
Unfortunately the second situation involving warnings, where clang warns about:
warning: empty macro arguments are a C99 feature [-Wc99-extensions]
coming from what I only see as a specific place in Boost PP in variadic/elem.hpp is not conducive to the same technique. In other words surrounding that one macro with:
# ifdef __clang__ # pragma clang diagnostic push # pragma clang diagnostic ignored "-Wc99-extensions" # endif
#define BOOST_PP_VARIADIC_ELEM(n, ...) BOOST_PP_CAT(BOOST_PP_VARIADIC_ELEM_, n)(__VA_ARGS__,)
# ifdef __clang__ # pragma clang diagnostic pop # endif
does not eliminate the warning at all ( I have reported this on the clang developers mailing list ). And since that macro is heavily used in Boost PP this warning occurs quite often when compiling Boost library code using Boost PP wih clang.
Are the warnings emitted upon the macro expansion? If so you could try embedding _Pragma into the macro.
The only other intrusive Boost PP solution to this problem is to treat clang like gcc as far as Boost PP variadic macro code is concerned: if the end-user compiles with one of the 'std=' dialects which explicitly supports variadic macros, such as 'std=c99', 'std=c++0x, 'std=c++11', then variadic macros are turned on in Boost PP for clang, else they are turned off. Do realize that both gcc and clang support variadic macros even when one of the 'std=' dialects are not chosen, and that in fact clang has always supported variadic macros. Also changing Boost PP support for clang and variadic macros would be a regression from the way it is now where it is always supported.
IMHO, if nothing helps then it is ok to enable variadic macros only when supported by the standard. That is the only condition we can require from compilers. Other cases are extension, which may not be usable and it's ok if we don't use it when it brings caveats like this.
I am testing now the local change so that clang is treated like gcc as far as variadic macro support in Boost PP is concerned. After I finish testing I will push the change to develop and, if nothing bad occurs in the regression tests, merge to master for the next release. This will get rid of all the clang warnings occuring in Boost PP during the various tests and library builds. This is the most effective way to eliminate the "warnings" headache from Boost PP variadic macro use when using clang without the appropriate 'std=' option.
On 17 Aug 2014 at 13:56, Edward Diener wrote:
The only other intrusive Boost PP solution to this problem is to treat clang like gcc as far as Boost PP variadic macro code is concerned: if the end-user compiles with one of the 'std=' dialects which explicitly supports variadic macros, such as 'std=c99', 'std=c++0x, 'std=c++11', then variadic macros are turned on in Boost PP for clang, else they are turned off.
Works for me. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
participants (3)
-
Andrey Semashev
-
Edward Diener
-
Niall Douglas