> IWYU tries to move the #include lines around and removes two of the three,
> which obviously breaks everything.  I tried marking the includes with "//
> IWYU pragma: keep", but that only made it keep the third, while it still
> removed the other two.  There needs to be some way to tell it to not touch
> the line at all -- perhaps pragma: keep should do that.

I'm experimenting with pragma: keep, and I agree it would be better if it caused duplicate
#includes to be preserved. Anyone disagree?

I can't think of a way other than an explicit pragma to let IWYU know what's going
on here.

I think the problem is that IWYU doesn't distinguish #include "nsEditPropertyAtomList.h".
It treats them like interchangeable, but in fact they are not. I'd like to fix this
problem instead of forcing developers to add pragma: keep manually.

Yes, pragma: keep would be a workaround. Maybe there should be a separate issue to track
the fact that pragma: keep cannot be used to keep multiple includes of the same file?

I blindly rejected the possibility of recognizing this construction (known as X-Macros:
[1]), but maybe it can be done...

Do you have any ideas for how to detect it? One thing that comes to mind is a rule
that says;

  If included.h uses a symbol defined in includer.x, before the line that
  #includes includer.h, keep the include line. And then something about it
  not being #undef:ed in between.

It's sort of the reverse of what IWYU is already doing.

I guess it's not limited to the preprocessor, either. It could be something like;

 // translation_unit.cc
 template<class T>
 struct Foo { };

 #include "foo_specializations.h"

 // foo_specializations.h
 template<> struct Foo<int> { static bool available = true; };
 template<> struct Foo<char> { static bool available = true; };
 template<> struct Foo<const char*> { static bool available = true; };

But if it's possible to cross-reference an included file with the file that includes
it, this might be doable.

[1] http://www.ddj.com/cpp/184401387

I just noticed this is a duplicate of issue #45, which has some further information.

If anyone wants to close this as a duplicate, though, please update the summary of issue
#45, because it's not descriptive at all.