make iwyu work for C code

[GoogleCodeExporter]

As far as I can tell, iwyu does not work well for C code, which means it can 
also not be used on projects (like ICU) that expose C APIs (sadly necessary for 
stable APIs from shared libraries) and/or contain .c implementation files.

Please accept pragmas inside /* C-style comments */, and please provide a way 
to mark a file as C code so that --comments writes /* C-style comments */.

Original issue reported on code.google.com by markus.icu on 5 May 2011 at 8:39

[GoogleCodeExporter]

This is a great idea!  Patch happily accepted.  Pragmas should work inside /* 
c-style comments */ even in C++ code.

As for --comments, it can try to guess what kind of comments to do based on the 
filename extension, or even better based on the file (if the file already has 
'//' that looks like a comment, use //-style comments, otherwise use /*-style 
comments).  Probably not worth adding another flag for this; fix_includes.py is 
getting too many flags already.

Original comment by csilv...@gmail.com on 12 May 2011 at 9:48

[GoogleCodeExporter]

I've created a patch to implement the first part of this (C-style comment 
pragmas), and added a couple of tests to tests/comment_pragmas.h

There is a little duplication in MaybeProtectInclude - it might be nice to 
refactor the code to avoid this.

As the 'keep' and 'export' pragmas are special cased in MaybeProtectInclude, 
I've added two separate tests (-d15.h and -d16.h) to cover these.

NB - to add a 'comment' a c-style iwyu pragma, you still need to use c++-style 
comment, e.g. :

/* IWYU pragma: keep // check C-style comments */

Original comment by paul.hol...@gmail.com on 17 Jul 2011 at 6:20

• Changed state: Started
• Added labels: Type-Enhancement, Usability
• Removed labels: Type-Defect

Attachments:

• c_style_comment_pragmas.patch

[GoogleCodeExporter]

Looks good to me.  Feel free to submit!

} /* IWYU pragma: keep // check C-style comments */

Can you also do
   /* IWYU pragma: keep */  /* check C-style comments */

If not, we should add a TODO to support that -- seems like the obvious way to 
do it.  Probably we'll just have to modify all the places that test for 
end-of-line, to test for */ as well.

Original comment by csilv...@gmail.com on 19 Jul 2011 at 12:07

[GoogleCodeExporter]

As it turns out, the /* */ /* */ seemed to work just fine (I updated the test 
to do that). It's also fine if there's no space between the token 'keep' and 
the closing */.

I've applied this in r272.

This only partially fixes this issue as raised - there's still the problem of 
emitting C-style comments in fix_includes.py.

Original comment by paul.hol...@gmail.com on 19 Jul 2011 at 10:51

[GoogleCodeExporter]

I'm not using fix-includes and it shows C++-style comments even in that log 
(under includes to add and complete list of includes), so if there is an issue 
in fix_includes.py then it's one of at least two places.

Original comment by ryan.pav...@gmail.com on 15 Sep 2011 at 6:29

[GoogleCodeExporter]

Are you just taking the output of iwyu and cutting-and-pasting it directly?  If 
so, then it's easy enough to put it through a filter that does something like
   sed 's,//.*$,/* \1 */,'

We need to fix fix_includes since it applies the fixes for you, so there's no 
chance to use a filter like this, but if you're doing things manually, a filter 
should work fine.

Original comment by csilv...@gmail.com on 21 Sep 2011 at 7:49

[GoogleCodeExporter]

I've been thinking about the best way to fix fix_includes.py.  My first thought 
is I would check if the file was a C or C++ file, but for .h files you can't 
tell by the extension.  I was thinking maybe we could tell by whether there are 
existing C++-style comments in the file, but many .h files may not have 
comments at all, but still be C++.

So now I agree with comment 5, that we *should* just fix the comments we emit 
in iwyu, and have fix_includes just take those comments verbatim (which it 
already does).  There's some work to fix fix_includes.py to accept /**/ as well 
as // in comments (in _COMMENT_RE and LINE_NUMBER_COMMENT_RE).  I also don't 
know how to ask clang if it's doing C or C++, though presumably that's not 
difficult.  Then we just need to fix 
iwyu_output.cc:PrintableIncludeOrForwardDeclareLine().

Though I guess there's still *more* machinery for fix_includes to do the 
merging if a .h file is analyzed twice, once in C mode and once in C++ mode.  
(This definitely happens.)  Fix-includes will have to munge comments on the fly 
to figure out they're the same.  Annoying.  It may be better to just fix this 
in a post-processing step and leave iwyu out of it. :-}

Original comment by csilv...@gmail.com on 25 Oct 2011 at 1:31

[GoogleCodeExporter]

Issue 122 has been merged into this issue.

Original comment by kim.gras...@gmail.com on 9 Feb 2014 at 12:20

[GoogleCodeExporter]

Wrt the comments.
As described in 122 I need to have /* */ after the #include, not // (as I am in 
a C shop and the coding style does not allow C++ comments (we use linux coding 
style).
I would already be quite happy with a flag that causes this comment style to be 
generated, even if fixincludes then does not work.
(btw fixincludes could optionally maybe do the sed script from comment 6)

Original comment by fransmeu...@gmail.com on 12 Feb 2014 at 8:26