[libcxx] r227226 - [libcxx] Make __wrap_iter work with gcc.

[Nico Weber]

On Tue, Jan 27, 2015 at 3:19 PM, David Blaikie <dblaikie at gmail.com> wrote:

>
>
> On Tue, Jan 27, 2015 at 11:27 AM, Nico Weber <nicolasweber at gmx.de> wrote:
>
>> Author: nico
>> Date: Tue Jan 27 13:27:39 2015
>> New Revision: 227226
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=227226&view=rev
>> Log:
>> [libcxx] Make __wrap_iter work with gcc.
>>
>> he following snippet doesn't build when using gcc and libc++:
>>
>>     #include <string>
>>     void f(const std::string& s) { s.begin(); }
>>     #include <vector>
>>     void AppendTo(const std::vector<char>& v) { v.begin(); }
>>
>> The problem is that __wrap_iter has a private constructor. It lists
>> vector<>
>> and basic_string<> as friends, but gcc seems to ignore this for vector<>
>> for
>> some reason. Declaring vector before the friend declaration in
>> __wrap_iter is
>> enough to work around this problem, so do that. With this patch, I'm able
>> to
>> build chromium/android with libc++. Without it, two translation units
>> fail to
>> build. (iosfwd already provides a forward declaration of basic_string.)
>>
>> As far as I can tell, this is due to a gcc bug, which I filed as
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64816.
>>
>> Fixes PR22355.
>>
>> http://reviews.llvm.org/D7201
>>
>> Added:
>>
>> libcxx/trunk/test/std/iterators/iterators.general/gcc_workaround.pass.cpp
>> Modified:
>>     libcxx/trunk/include/iterator
>>
>> Modified: libcxx/trunk/include/iterator
>> URL:
>> http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/iterator?rev=227226&r1=227225&r2=227226&view=diff
>>
>> ==============================================================================
>> --- libcxx/trunk/include/iterator (original)
>> +++ libcxx/trunk/include/iterator Tue Jan 27 13:27:39 2015
>> @@ -1112,6 +1112,8 @@ typename enable_if
>>  >::type
>>  __unwrap_iter(__wrap_iter<_Tp*>);
>>
>> +template <class _Tp, class _Alloc> class _LIBCPP_TYPE_VIS_ONLY vector;
>>
>
> Worth including a comment that this is a workaround for a particular bug
>

I went with the prevalent documentation style in libc++ :-)


> (is there a GCC bug filed for this?)?
>

Yes, see this snippet in the CL description:

"""
As far as I can tell, this is due to a gcc bug, which I filed as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64816.
"""

There's some more rambling on the topic (a link to a clang bug I found
while working on this, etc) in the mentioned PR22355 too.


>
>
>> +
>>  template <class _Iter>
>>  class __wrap_iter
>>  {
>>
>> Added:
>> libcxx/trunk/test/std/iterators/iterators.general/gcc_workaround.pass.cpp
>> URL:
>> http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/std/iterators/iterators.general/gcc_workaround.pass.cpp?rev=227226&view=auto
>>
>> ==============================================================================
>> ---
>> libcxx/trunk/test/std/iterators/iterators.general/gcc_workaround.pass.cpp
>> (added)
>> +++
>> libcxx/trunk/test/std/iterators/iterators.general/gcc_workaround.pass.cpp
>> Tue Jan 27 13:27:39 2015
>> @@ -0,0 +1,20 @@
>>
>> +//===----------------------------------------------------------------------===//
>> +//
>> +//                     The LLVM Compiler Infrastructure
>> +//
>> +// This file is dual licensed under the MIT and the University of
>> Illinois Open
>> +// Source Licenses. See LICENSE.TXT for details.
>> +//
>>
>> +//===----------------------------------------------------------------------===//
>> +
>> +// Tests workaround for
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64816.
>> +
>> +#include <string>
>> +
>> +void f(const std::string &s) { s.begin(); }
>> +
>> +#include <vector>
>> +
>> +void AppendTo(const std::vector<char> &v) { v.begin(); }
>> +
>> +int main() {}
>>
>>
>> _______________________________________________
>> cfe-commits mailing list
>> cfe-commits at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>>
>
>
> _______________________________________________
> cfe-commits mailing list
> cfe-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20150127/a3ecd565/attachment.html>