[cfe-dev] Latest Windows build with VC++ 12 breaks preprocessor

Edward Diener eldlistmailingz at tropicsoft.com
Wed Jul 9 17:19:18 PDT 2014


On 7/8/2014 2:19 AM, Edward Diener wrote:
> I am trying to test the latest build of clang using the VC++12 IDE with
> Boost libraries. This build creates the version of clang executed as
> clang-cl.exe.
>
> I am actively involved with the Boost PP library. The tests for
> preprocessor macros in this library are a good indication of correct
> preprocessor macro expansion.
>
> Previous versions of clang are able to pass all the tests. However the
> latest version of clang-cl.exe for Windows fails one of the tests, so
> some change made in the preprocessor is causing breakage. I will start
> by giving the macro expansion that fails with a clang error. I do want
> to first point out that not only previous versions of clang pass the
> same tests but that all versions of gcc pass the tests and that the
> particular failure of clang, when run under the Boost Wave preprocessor,
> also expands the macro successfully. Since Boost PP is quite complicated
> and uses largely very clever macro preprocessing implemented largely by
> Paul Mensonides and on a lesser scale by myself, it is hard to pinpoint
> why the latest clang in Windows using VC++ is failing the particular
> macro expansion. Nonetheless the expansion which fails is:
>
> # define SEQ_NONE ()
> BOOST_PP_SEQ_TO_LIST(SEQ_NONE)
>
> The expansion should create a Boost PP list of the form:
>
> (,BOOST_PP_NIL)
>
> which is a totally valid Boost PP list. Instead one gets from clang-cl.exe:
>
> "..\..\..\boost/preprocessor/seq/to_list.hpp(22,59) :  note: expanded
> from macro 'BOOST_PP_SEQ_TO_LIST'
> # define BOOST_PP_SEQ_TO_LIST(seq)
> BOOST_PP_SEQ_TO_LIST_I(BOOST_PP_SEQ_BINARY_TRANSFORM(seq))
>                                                            ^
> ..\..\..\boost/preprocessor/seq/detail/binary_transform.hpp(29,61) :
> note: expanded from macro 'BOOST_PP_SEQ_BINARY_TRANSFORM'
> #    define BOOST_PP_SEQ_BINARY_TRANSFORM(seq)
> BOOST_PP_CAT(BOOST_PP_SEQ_BINARY_TRANSFORM_A seq, 0)
>                                                              ^
> ..\..\..\boost/preprocessor/seq/detail/binary_transform.hpp(39,114) :
> note: expanded from macro 'BOOST_PP_SEQ_BINARY_TRANSFORM_A'
> #    define BOOST_PP_SEQ_BINARY_TRANSFORM_A(...)
> (BOOST_PP_SEQ_BINARY_TRANSFORM_GET_REM(__VA_ARGS__), __VA_ARGS__)()
> BOOST_PP_SEQ_BINARY_TRANSFORM_B
>
>                                            ^
> ..\..\..\boost/preprocessor/cat.hpp(22,47) :  note: expanded from macro
> 'BOOST_PP_CAT'
> #    define BOOST_PP_CAT(a, b) BOOST_PP_CAT_I(a, b)
>                                                ^
> ..\..\..\boost/preprocessor/cat.hpp(29,34) :  note: expanded from macro
> 'BOOST_PP_CAT_I'
> #    define BOOST_PP_CAT_I(a, b) a ## b
>                                   ^
> ..\..\..\boost/preprocessor/seq/to_list.hpp(23,62) :  note: expanded
> from macro 'BOOST_PP_SEQ_TO_LIST_I'
> # define BOOST_PP_SEQ_TO_LIST_I(bseq) BOOST_PP_SEQ_TO_LIST_A bseq
> BOOST_PP_NIL BOOST_PP_SEQ_TO_LIST_B bseq
>                                                               ^
> ..\..\..\boost/preprocessor/seq/to_list.hpp(24,10) :  note: macro
> 'BOOST_PP_SEQ_TO_LIST_A' defined here
> # define BOOST_PP_SEQ_TO_LIST_A(m, e) m(BOOST_PP_LPAREN() e
> BOOST_PP_COMMA() BOOST_PP_SEQ_TO_LIST_A_ID)
>           ^
> In file included from seq.cpp:14:
> ..\..\..\libs/preprocessor/test/seq.cxx(117,42) :  error: too few
> arguments provided to function-like macro invocation"
>
> Meanwhile a Boost PP sequence which is not a single empty element works
> correctly in clang, so that:
>
> # define SEQ (4)(1)(5)(2)
> BOOST_PP_SEQ_TO_LIST(SEQ)
>
> correctly expands to:
>
> (4,(1,(5,(2,BOOST_PP_NIL))))
>
> I realize this is hard to describe in order to bring this to the
> attention of clang developers, especially if they are not cognizant of
> Boost or Boost PP, and I also realize I can create a bug report for
> clang. But I thought I would try to describe it here in case whoever has
> changed the macro expansion code in the preprocessor might realize that
> whatever was changed has broken something in the preprocessor.

I have filed a bug report on this bug and it is at:

http://llvm.org/bugs/show_bug.cgi?id=20277





More information about the cfe-dev mailing list