Errors in libc++. iterator test fails

[GoogleCodeExporter]

Steps to reproduce:
Prerequisites: system where libc++ is default stdlib, for example, Mac OS X 
10.9+.
1. Run iterator.cc test.

Actual result:
Test fails.  In addition to unexpected diagnostic errors, IWYU erroneously 
recommends to add <iterator>
    #include <iterator>  // for __wrap_iter, operator!=, reverse_iterator

Expected result:
Test should pass.

Original issue reported on code.google.com by vsap...@gmail.com on 7 Jun 2014 at 6:53

[GoogleCodeExporter]

This fails miserably on MSVC too, I think the special handling for iterators is 
very libstdc++-centric.

Original comment by kim.gras...@gmail.com on 7 Jun 2014 at 7:01

[GoogleCodeExporter]

IWYU has special code to handle iterators for various STL classes.  See 
MapPrivateDeclToPublicType, DeclIsTemplateWithNameAndNumArgsAndTypeArg for more 
details.

The problem is that IWYU checks implementation-defined iterator types, which 
are different in libstdc++ and libc++.  For example, libstdc++ uses 
__normal_iterator and libc++ - __wrap_iter.  I've fixed the issue by adding 
support for libc++ iterators.  I have to point out that 
libstdc++ vector<int>::iterator is __normal_iterator<int, vector<int>>, which 
maps to vector<int> 
and libc++ vector<int>::iterator is __wrap_iter<int*>, which maps to int*.  
Such libc++ remapping looks suspicious, but everything works.

I am also reviewing iterators for other STL containers and will submit separate 
issue.  For example, vector<bool> uses custom bit iterator, which isn't handled 
by IWYU (__bit_iterator and _Bit_iterator  in libc++ and libstdc++ 
respectively).

Original comment by vsap...@gmail.com on 7 Jun 2014 at 7:13

Attachments:

• libcxx_iterator.patch

[GoogleCodeExporter]

Looks good to me. All (expected) tests pass on Windows.

I was thinking that the comments might benefit from being generalized instead 
of just adding specific information about libc++, but since this code is so 
specialized anyway it's probably better to be specific.

It would be interesting to see if any general patterns (across library impls) 
emerge in this mapping so we can make it more data-driven, but we can worry 
about that later.

Original comment by kim.gras...@gmail.com on 8 Jun 2014 at 10:26

[GoogleCodeExporter]

This issue was closed by revision r556.

Original comment by vsap...@gmail.com on 8 Jun 2014 at 5:05

• Changed state: Fixed