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
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
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