C++11 file fails to compile under IWYU with libstdc++ 4.8

[GoogleCodeExporter]

//Example:
#include <memory>
#include <string>
int main() {
    std::unique_ptr<std::string> p(new std::string("dsf"));
    std::make_pair("sdfasf", std::move(p));
    return 0;
}

Running:
include-what-you-use pair.cc -std=c++11
gives:
In file included from pair.cc:1:
In file included from 
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../include/c++/4.8/memory:62:
In file included from 
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../include/c++/4.8/bits/stl_algoba
se.h:64:
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../include/c++/4.8/bits/stl_pair.h
:113:21: error: call to deleted constructor of 
'std::unique_ptr<std::basic_string<char>, 
std::default_delete<std::basic_string<char> > >'
      : first(__a), second(__b) { }
                    ^      ~~~
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../include/c++/4.8/bits/stl_pair.h
:281:14: note: in instantiation of member function 'std::pair<const char *, 
std::unique_ptr<std::basic_string<char>, 
std::default_delete<std::basic_string<char> > > >::pair' requested here
      return __pair_type(std::forward<_T1>(__x), std::forward<_T2>(__y));
             ^
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../include/c++/4.8/bits/unique_ptr
.h:273:7: note: function has been explicitly marked deleted here
      unique_ptr(const unique_ptr&) = delete;

Compiling with normal clang (same version 3.4.1) gives no problems. I suspect 
that some built-in defines are different between clang and IWYU, causing the 
problem in libstdc++.

Original issue reported on code.google.com by rol...@rschulz.eu on 28 May 2014 at 7:19

• Blocked on: #118

[GoogleCodeExporter]

Thanks for the report! I believe this is the same problem as issue 118. IWYU is 
more aggressive than a C++ compiler about instantiating templates, because it 
needs to check the template pattern for uses, independent of whether it's 
instantiated or not.

We can use this as an additional test case, but otherwise I think it's a plain 
duplicate.

Original comment by kim.gras...@gmail.com on 28 May 2014 at 5:50

[GoogleCodeExporter]

roland, could you try the last patch attached to issue 118 and see if it fixes 
this problem as well? It looks slightly different, but I don't have access to a 
libstdc++ toolchain so I can't readily test it.

Original comment by kim.gras...@gmail.com on 29 May 2014 at 8:32

[GoogleCodeExporter]

Yes. The patch fixes this problem. Now with both libc++ and libstdc++ I get:
pair.cc should add these lines:
#include <type_traits>                  // for remove_reference<>::type

Given that remove_reference isn't used directly put only indirectly through 
move this shouldn't be suggested.

For libc++ it also suggests:
#include "iosfwd"                       // for string
#include "new"                          // for operator new

It seems there isn't a correct mapping for libc++ yet. 

Should I create 2 new issues for each of those?

Original comment by rol...@rschulz.eu on 30 May 2014 at 3:21

[GoogleCodeExporter]

Great!

Yes, please create new issues for the other two cases.

Original comment by kim.gras...@gmail.com on 30 May 2014 at 6:20

• Now blocked on: #118

[GoogleCodeExporter]

Roland has created issue #142 for unnecessary type_traits and issue #141 for 
unnecessary iosfwd.

Roland, is it OK to close the current issue?

Original comment by vsap...@gmail.com on 3 Jun 2014 at 10:18

[GoogleCodeExporter]

Yes. It can be closed.

Original comment by rol...@rschulz.eu on 5 Jun 2014 at 5:40

[GoogleCodeExporter]

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

• Changed state: Fixed