clang failing core/detail_iterator_test?
Does anyone have any idea why Clang doesn't like detail_iterator_test? As an example, http://www.boost.org/development/tests/develop/developer/output/BP%20x86_64%... ../libs/core/test/detail_iterator_test.cpp:79:76: error: no member named 'iterator_category' in 'boost::detail::iterator_traits<iterator<C, T, D, P, R> >' BOOST_TEST_TRAIT_TRUE((is_same<boost::detail::iterator_traits<It>::iterator_category,C>)); ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^ I'm having endless trouble trying to get a version of Clang up and running here (on Windows), as is customary. This: ../libs/core/test/detail_iterator_test.cpp:136:17: error: default initialization of an object of const type 'const T [5]' T const x[ N ]; ^ I know what is about, and I've fixed that already.
On Saturday 07 June 2014 00:03:57 Peter Dimov wrote:
I'm having endless trouble trying to get a version of Clang up and running here (on Windows), as is customary.
I got the latest SVN Clang running, but now the test doesn't fail. Go figure. They must've fixed something.
I can reproduce it locally with clang 3.4. Shows only with -std=c++11 - stdlib=libc++. Trying to dig further.
On Saturday 07 June 2014 01:09:39 you wrote:
On Saturday 07 June 2014 00:03:57 Peter Dimov wrote:
I'm having endless trouble trying to get a version of Clang up and running here (on Windows), as is customary.
I got the latest SVN Clang running, but now the test doesn't fail. Go figure. They must've fixed something.
I can reproduce it locally with clang 3.4. Shows only with -std=c++11 - stdlib=libc++. Trying to dig further.
Ok, here's the thing. libc++ only implements std::iterator_traits for class- type iterators if they have nested iterator_category typedef, and this typedef is one of the std:: iterator categories. Otherwise std::iterator_traits is empty. Replacing struct C { }; with typedef std::random_access_iterator_tag C; fixes the compilation for me.
Andrey Semashev wrote:
I can reproduce it locally with clang 3.4. Shows only with -std=c++11 -stdlib=libc++. Trying to dig further.
Ah. Sneaky hobbits. Conforming extension my posterior. :-) (Actually, it _is_ a conforming extension, by a strict reading of the standard. Still, I'd have preferred a little less cleverness.) template <class _Tp> struct __has_iterator_category { private: struct __two {char __lx; char __lxx;}; template <class _Up> static __two __test(...); template <class _Up> static char __test(typename _Up::iterator_category* = 0); public: static const bool value = sizeof(__test<_Tp>(0)) == 1; }; template <class _Iter, bool> struct __iterator_traits_impl {}; template <class _Iter> struct __iterator_traits_impl<_Iter, true> { typedef typename _Iter::difference_type difference_type; typedef typename _Iter::value_type value_type; typedef typename _Iter::pointer pointer; typedef typename _Iter::reference reference; typedef typename _Iter::iterator_category iterator_category; }; template <class _Iter, bool> struct __iterator_traits {}; template <class _Iter> struct __iterator_traits<_Iter, true> : __iterator_traits_impl < _Iter, is_convertible<typename _Iter::iterator_category, input_iterator_tag>::value || is_convertible<typename _Iter::iterator_category, output_iterator_tag>::value > {}; // iterator_traits<Iterator> will only have the nested types if Iterator::iterator_category // exists. Else iterator_traits<Iterator> will be an empty class. This is a // conforming extension which allows some programs to compile and behave as // the client expects instead of failing at compile time. template <class _Iter> struct _LIBCPP_TYPE_VIS_ONLY iterator_traits : __iterator_traits<_Iter, __has_iterator_category<_Iter>::value> {};
On 06/06/2014 02:53 PM, Peter Dimov wrote:
Andrey Semashev wrote:
I can reproduce it locally with clang 3.4. Shows only with -std=c++11 -stdlib=libc++. Trying to dig further.
Ah. Sneaky hobbits. Conforming extension my posterior. :-)
(Actually, it _is_ a conforming extension, by a strict reading of the standard. Still, I'd have preferred a little less cleverness.)
std::iterator_traits will be required to be SFINAE-friendly. See n3923: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3923.pdf There was a debate in the Redmond meeting about making the testing for iterator_category strict, like Howard has it in libc++. That was voted down. I think Howard is going to have to change libc++ in this regard. Eric
Eric Niebler wrote:
On 06/06/2014 02:53 PM, Peter Dimov wrote:
Andrey Semashev wrote:
I can reproduce it locally with clang 3.4. Shows only with -std=c++11 -stdlib=libc++. Trying to dig further.
Ah. Sneaky hobbits. Conforming extension my posterior. :-)
(Actually, it _is_ a conforming extension, by a strict reading of the standard. Still, I'd have preferred a little less cleverness.)
std::iterator_traits will be required to be SFINAE-friendly. See n3923:
No problem. SFINAE-friendly means replacing a "hard" compile-time error on iterator_traits<It>::iterator_category with a "soft" compile-time error. That's different from replacing a lack of an error with a "soft" compile-time error though.
On Saturday, June 07, 2014 01:34 PM, Eric Niebler wrote:
I think Howard is going to have to change libc++ in this regard.
Actually, I think that will more likely fall to Marshall these days. https://groups.google.com/forum/#!topic/llvm-dev/3R0pNrB6Mqg Ben
participants (4)
-
Andrey Semashev
-
Ben Pope
-
Eric Niebler
-
Peter Dimov