Does not recognize that .C files are not headers and thus may have a corresponding .h

[GoogleCodeExporter]

Found when trying to use with VRPN, which uses .C for c++ source files.  A 
change was required in only one file, though in two places.  Patch (simple) is 
attached. Tested to have the desired effect (changes now suggested for both .C 
and .h files in VRPN)

Original issue reported on code.google.com by ryan.pav...@gmail.com on 20 Nov 2012 at 7:25

Attachments:

• add_C_as_extension.diff

[GoogleCodeExporter]

Thanks for the contribution, Ryan. But what if we compare lowercase extension? 
Extensions .cpP, .cPP look ridiculous, but they are valid as far as I can tell. 
And comparing lowercase extension will help not only with .C extension, but 
with other extensions too.

Original comment by vsap...@gmail.com on 22 Nov 2012 at 12:07

[GoogleCodeExporter]

That makes sense, as long as we limit use to only C++ files, since the language 
flag -x c++ is passed in from somewhere, IIRC.

Alternately, it seems as though Clang has a method of guessing the language of 
a file since I don't typically have to pass a -x option - could that be used 
instead of rolling our own?

Original comment by ryan.pav...@gmail.com on 26 Nov 2012 at 9:32

[GoogleCodeExporter]

Related to issue 82. Patch for 82 will also add explicit support for upper-case 
.C and .CC (for consistency with fix_include.py, which supported .CC)

No other case variations addressed.

Original comment by kim.gras...@gmail.com on 10 Dec 2012 at 4:03

[GoogleCodeExporter]

Resolved as a part of issue #82.

I was wrong about Clang supporting all case variations, so IWYU doesn't need to 
support all variations too.

Original comment by vsap...@gmail.com on 30 Dec 2012 at 8:26

• Changed state: Fixed