Closed voivoid closed 9 months ago
This was also reported to MSVC as DevCom-10565526 "boost::spirit fails to compile with /std:c++20 with MSVC 19.34+". It happens with /std:c++20
and VS 2022 17.4 because we implemented P2520R0 "move_iterator<T*>
should be a random access iterator" (which is a C++23 feature) "downlevel" in C++20 mode (treating it as a defect report, in alignment with libstdc++ and libc++). Both MSVC's compiler and clang-cl repro this with MSVC's STL, and clang-cl emits a more understandable error.
What's happening is that boost_1_84_0\boost/spirit/home/x3/operator/detail/sequence.hpp(383,39)
is calling std::make_move_iterator()
on a std::vector<ast::Item>::iterator
. Due to P2520R0, std::move_iterator
has to ask whether the wrapped iterator models std::random_access_iterator
. Obviously (to humans) this is true for a std::vector::iterator
, but the library doesn't short-circuit that check, it has to actually evaluate the concept. This has to ask whether the iterator is std::totally_ordered
, and that ends up asking whether the std::vector<ast::Item>::iterator
s can be compared with >
.
This ends up considering the following unconstrained operator>
overload in boost::spirit::x3
, instantiating it for std::vector<ast::Item>::iterator
:
The std::totally_ordered
concept (actually our implementation detail std::_Half_ordered
, but that doesn't matter) just wants to know whether vector_iterator > vector_iterator
is well-formed and boolean-testable, but while performing overload resolution, it has to consider Boost.Spirit's unconstrained operator>
, and the return type is auto
so it has to instantiate the operator's function body. This causes a hard (non-SFINAE-able) compiler error because whatever left >> expect[right]
does, it is not prepared for this to be used with std::vector<ast::Item>::iterator
.
Therefore, this is a bug in Boost.Spirit, not MSVC. (I can't explain why it doesn't repro with libstdc++ and libc++, even with their debug modes - the implementation details of std::vector
may be relevant.) I believe the fix would involve constraining this boost::spirit::x3::operator>
overload, but I'm not 100% sure. Hope this helps!
I believe the fix would involve constraining this
boost::spirit::x3::operator>
overload
Implementing own move_iterator
might be a way forward to avoid using C++20 features (and relying on conditional compilation to support C++17)
All operators are constrained by SFINAE on return type except operator>
, that's inconsistent. But I also thinking about moving types users can inherit from to a separate namespace because SFINAEd-out operators unnecessarily pollutes compiler error messages (which are on their own are hard for users to understand).
MSVC fails to compile annotation example if /std:c++20 or /std:c++latest is set. Everything is fine with /std:c++17.
See compiler explorer to get the bug reproduction
Unfortunately the error message ( can be seen in the provided link ) is pretty cryptic so I'm not sure whether it's a MSVC or boost::spirit problem.