including spirit multi_pass and info header files caused compile error

[zhuo.qiang@…]

It seems the 2 header files

• boost/spirit/include/support_info.hpp
• boost/spirit/include/support_multi_pass.hpp

are not getting along very well using clang and its libc++ under c++11

If the 2 files are included in the same complie unit (either directly or indirectly) like following:

#include <boost/spirit/include/support_info.hpp>
#include <boost/spirit/include/support_multi_pass.hpp>

It will fail the clang with flag '-std=c++11', '-stdlib=libc++'

clang++ -o test.o -c -std=c++11 -stdlib=libc++ -I/Users/qiang/Projects/boost_1_51_0 test.cpp
In file included from test.cpp:1:
In file included from /Users/qiang/Projects/boost_1_51_0/boost/spirit/include/support_info.hpp:15:
In file included from /Users/qiang/Projects/boost_1_51_0/boost/spirit/home/support/info.hpp:19:
/usr/bin/../lib/c++/v1/list:212:9: error: field has incomplete type 'boost::spirit::info'
    _Tp __value_;
        ^
/usr/bin/../lib/c++/v1/type_traits:1889:54: note: in instantiation of template class 'std::__1::__list_node<boost::spirit::info, void *>' requested here
decltype(_VSTD::move(_Tp(_VSTD::declval<_Args>()...)), true_type())
                                                     ^
...

Attachment is the complete error message.

Reproduced in

• Apple clang version 4.1 (tags/Apple/clang-421.11.65) (based on LLVM 3.1svn)
• Target: x86_64-apple-darwin12.2.0
• With C++ 11 turn on: "-std=c++11 -stdlib=libc++" , the 2 flags must be turned on at the same time to reproduce this bug
• Boost 1.51 and Boost Trunk rev.81030

[zhuo.qiang@…]

The full compile error message

[Fedor Sergeev <Fedor.Sergeev@…>]

I'm getting the same failure with Oracle Solaris Studio C++ 12.4 compiler. Works fine for -std=c++03 and fails with 'incomplete type "boost::spirit::info"' for -std=c++11.

[Fedor Sergeev <Fedor.Sergeev@…>]

At least for Studio C++ it looks like a bug in compiler when handling alignment_of<recursive_wrapper<incomplete_type>> where implementation of alignment_of goes through the alignment_of_hack path.

Workaround found: -DBOOST_ALIGNMENT_OF=__alignof

[Joel de Guzman]

could not reproduce with boost-1.51 and clang 3.4, probably a fixed bug in libc++