Empty output should be removed

[GoogleCodeExporter]

Using iwyu with this code
----
#include <stdio.h>
#include <malloc.h>
#include <limits.h>

int foo(void) {
        fprintf(stderr, "an error\n");
        return INT_MAX;
}
----

will display

foo.c should add these lines:

foo.c should remove these lines:
- #include <malloc.h>  // lines 2-2

Since the "should add these lines:" is empty, this line can be removed.

Original issue reported on code.google.com by sylvestre.ledru on 7 Sep 2013 at 10:59

[GoogleCodeExporter]

The '... should add these lines' text is currently used as an anchor to find 
the summary output in the IWYU tests.

Not sure how this was chosen, but maybe we should think about emitting a 'IWYU 
summary for $filename' as a heading instead.

Original comment by kim.gras...@gmail.com on 8 Sep 2013 at 3:01

[GoogleCodeExporter]

Also it is incorrect to use plural when IWYU recommends to add/remove a single 
line.

This issue is complicated by the fact that IWYU output has to be parseable. As 
Kim has mentioned, IWYU tests use 'should add these lines' string. Also it is 
used in fix_includes.py.

So the text isn't always changed properly, but fixed text is easier to parse. I 
cannot promise that this issue will be fixed soon. At first I'd like to see how 
many users are concerned with this issue.

Original comment by vsap...@gmail.com on 8 Sep 2013 at 5:53

[GoogleCodeExporter]

For the export aspect, you could consider json or XML exporter...

Original comment by sylvestre.ledru on 9 Sep 2013 at 7:21

[GoogleCodeExporter]

I wonder if IWYU should output a unified diff instead? Or does that not work 
for some reason? That way fix_includes.py could be replaced by the patch 
command.

Original comment by kim.gras...@gmail.com on 21 Sep 2013 at 11:49

[GoogleCodeExporter]

A diff would be great. However, from an editor integration perspective, I still 
think that json/xml is easier for them to display warnings/errors.

Original comment by sylvestre.ledru on 21 Sep 2013 at 12:36

[GoogleCodeExporter]

And another option is to output IWYU recommendations in 
clang-apply-replacements format.

Original comment by vsap...@gmail.com on 6 Oct 2013 at 7:45

[GoogleCodeExporter]

I've been thinking about that lately, but from another perspective -- the work 
done for clang-modernize/clang-apply-replacements seems to account for 
de-duplication of changes. That might be a way to do "whole-program" analysis, 
i.e. run over multiple translation units and headers without generating 
conflicts.

It might be that IWYU is more difficult than clang-modernize, though, as 
re-writing #includes changes the universe for a compilation unit, but it would 
be interesting to investigate further.

Original comment by kim.gras...@gmail.com on 7 Oct 2013 at 4:43