Test badinc fails on Mac

[GoogleCodeExporter]

badinc fails with message
AssertionError: 
tests/badinc.cc:1136: Unexpected diagnostic:
errno is defined in <sys/errno.h>, which isn't directly #included.

tests/badinc.cc:1616: Unexpected diagnostic:
I2_Enum is defined in "tests/badinc-i2.h", which isn't directly #included.

tests/badinc.h:133: Unexpected diagnostic:
errno is defined in <sys/errno.h>, which isn't directly #included.

Unexpected summary diffs for tests/badinc.h:
+++  
@@ -1,5 +1,6 @@
 tests/badinc.h should add these lines:
 #include <stdio.h>
+#include <sys/errno.h>
 #include <set>
 #include <utility>
 #include <vector>
@@ -8,14 +9,15 @@

 tests/badinc.h should remove these lines:
 - #include <ctype.h>  // lines XX-XX
+- #include <errno.h>  // lines XX-XX
 - #include <math.h>  // lines XX-XX
 - #include "tests/badinc-d2.h"  // lines XX-XX
 - class H_ForwardDeclareClass;  // lines XX-XX
 - template <typename T> class I2_TypedefOnly_Class;  // lines XX-XX

 The full include-list for tests/badinc.h:
-#include <errno.h>  // for errno
 #include <stdio.h>  // for NULL, printf
+#include <sys/errno.h>  // for errno
 #include <queue>  // for queue
 #include <set>  // for set
 #include <string>  // for string

---

Can somebody check if this failure is encountered on other platforms or is it 
Mac-specific? I am especially interested in I2_Enum.

Using LLVM/Clang r162648, IWYU r371 on Mac OS X 10.6.8.

Original issue reported on code.google.com by vsap...@gmail.com on 26 Aug 2012 at 8:14

[GoogleCodeExporter]

This issue is similar to issue #22. I think it is better to create a new issue 
than to dig up an old closed issue.

Original comment by vsap...@gmail.com on 26 Aug 2012 at 8:17

[GoogleCodeExporter]

I pulled out the same revisions and built on my Windows/VS2010 machine.

There are lots of test failures, but I don't see the unexpected I2_Enum 
diagnostic.

Line 1616 is preceded by this, though:

  // TODO(csilvers): IWYU: I2_Enum is...*badinc-i2.h
  // IWYU: std::vector is...*<vector>
  delete newed_vector;

so maybe this is intended? I can check this on Ubuntu later, and see if it 
happens there with later LLVM revs. I haven't seen it before.

- Kim

Original comment by kim.gras...@gmail.com on 26 Aug 2012 at 11:39

[GoogleCodeExporter]

LLVM/Clang r162947 and IWYU r372 built with GCC version 4.6.3 on Ubuntu 12.04.

- Test passes
- No unexpected diagnostics
- No mention of I2_Enum on line 1616 whatsoever

For what it's worth...

Original comment by kim.gras...@gmail.com on 30 Aug 2012 at 10:59

[GoogleCodeExporter]

Thanks Kim for checking. Now I can close issues which were still open because 
tests don't pass.

Original comment by vsap...@gmail.com on 2 Sep 2012 at 5:45

[GoogleCodeExporter]

For posterity, badinc.cc fails on my BSD machine too. I figured this might be 
interesting, because FreeBSD 10.1 uses libc++ just like Mac OSX (albeit another 
version).

Besides the I2Enum problem (two diagnostics) I also see IWYU confusing <string> 
and <iosfwd>.

Here's the output:

tests/cxx/badinc.cc:1556: Unexpected diagnostic:
I2_Enum is defined in "tests/cxx/badinc-i2.h", which isn't directly #included.

tests/cxx/badinc.cc:1602: Unexpected diagnostic:
I2_Enum is defined in "tests/cxx/badinc-i2.h", which isn't directly #included.

tests/cxx/badinc.cc:1775: Unmatched regex:
std::vector is...*<vector>

tests/cxx/badinc.cc:1799: Unmatched regex:
std::vector is...*<vector>

tests/cxx/badinc.cc:1812: Unmatched regex:
std::vector is...*<vector>

tests/cxx/badinc.h:124: Unexpected diagnostic:
std::string is defined in <iosfwd>, which isn't directly #included.

tests/cxx/badinc.h:126: Unexpected diagnostic:
std::string is defined in <iosfwd>, which isn't directly #included.

Unexpected summary diffs for tests/cxx/badinc.cc:
+++
@@ -36,10 +36,10 @@
 #include <stddef.h>  // for offsetof, size_t
 #include <stdlib.h>  // for rand
 #include <algorithm>  // for find
-#include <fstream>  // for fstream
+#include <fstream>  // for fstream, string
 #include <list>  // for list
 #include <new>  // for operator new
-#include <string>  // for allocator, basic_string, basic_string<>::iterator, 
char_traits, operator+, string
+#include <string>  // for allocator, basic_string, basic_string<>::iterator, 
operator+
 #include <typeinfo>  // for type_info
 #include "tests/cxx/badinc-d1.h"  // for D1CopyClassFn, D1Function, D1_Class, D1_CopyClass, D1_Enum, D1_Enum::D11, D1_I1_Typedef, D1_StructPtr, D1_Subclass, D1_TemplateClass, D1_TemplateStructWithDefaultParam, MACRO_CALLING_I4_FUNCTION
 #include "tests/cxx/badinc-d4.h"  // for D4_ClassForOperator, operator<<
---

Unexpected summary diffs for tests/cxx/badinc.h:
+++
@@ -1,5 +1,6 @@
 tests/cxx/badinc.h should add these lines:
 #include <stdio.h>
+#include <iosfwd>
 #include <set>
 #include <utility>
 #include <vector>
@@ -9,6 +10,7 @@
 tests/cxx/badinc.h should remove these lines:
 - #include <ctype.h>  // lines XX-XX
 - #include <math.h>  // lines XX-XX
+- #include <string>  // lines XX-XX
 - #include "tests/cxx/badinc-d2.h"  // lines XX-XX
 - class H_ForwardDeclareClass;  // lines XX-XX
 - template <typename T> class I2_TypedefOnly_Class;  // lines XX-XX
@@ -16,9 +18,9 @@
 The full include-list for tests/cxx/badinc.h:
 #include <errno.h>  // for errno
 #include <stdio.h>  // for NULL, printf
+#include <iosfwd>  // for string
 #include <queue>  // for queue
 #include <set>  // for set
-#include <string>  // for string
 #include <utility>  // for pair
 #include <vector>  // for vector
 #include "tests/cxx/badinc-d3.h"  // for D3_Enum, D3_Enum::D31

Original comment by kim.gras...@gmail.com on 2 Mar 2015 at 8:58

[GoogleCodeExporter]

To fix iosfwd issue I was toying with idea that if file with typedef is 
included by typedef underlying type, then underlying type reexports typedef. 
I've tried 2 approaches:

1) replacing typedef usage with underlying type usage. I don't like it because 
in the end we report we use <string> for basic_string, not for string. Also 
replacing one symbol usage with another symbol feels wrong.

2) adding a mapping between typedef and underlying type. One problem is that we 
shouldn't modify mappings in GlobalIncludePicker during AST traversal. And 
another problem is that we don't have a clear way to represent such mapping. If 
I can forward declare std::string, I should include <iosfwd>, and if I need 
full usage, then I should include <string>. Manual mapping should be easier, 
but we still have to solve how to represent such mappings.

So far I haven't investigated any of these approaches further.

Side note: this issue made me notice that ideally we shouldn't mention 
basic_string in file symbols, unless it is used explicitly. But that's a 
separate issue.

Original comment by vsap...@gmail.com on 14 Mar 2015 at 7:12