Support "#include MACRO // IWYU pragma"

[GoogleCodeExporter]

What steps will reproduce the problem?  Give the *exact* arguments passed
to include-what-you-use, and attach the input source file that gives the
problem (minimal test-cases are much appreciated!)
1. export.h
#define MY_INCLUDE_FILE "important_port.h"
#include MY_INCLUDE_FILE  // IWYU pragma: export

2. use.cpp
#include "export.h"
//use something from important_port.h

What is the expected output? What do you see instead?
Expect a pass, instead get an error.

What version of the product are you using? On what operating system?
This is the one in Ubuntu Trusty (which might actually start working in the 
future... see https://bugs.launchpad.net/ubuntu/+source/iwyu/+bug/1363322 ). So 
the 3.3 version. I know it's an old version, and I will see if this persists in 
a newer version, but if I don't report this now I'll forget.

Please provide any additional information below.
This is one of those "marcros mess up everything" sorts of things. FreeType for 
example uses this pattern where you include <ft2build.h> and then all other 
includes are FT_XXX_H macros. There's also a use of this in Skia, where certain 
ports may need build configurable headers, and those headers are specified to 
the build system as SK_XXX_PLATFORM_H defines. Iwyu seems to have issues with 
these, perhaps applying pragmas before the macro expansion. Also, it would be 
nice if the recommendations used the macro-ized original names instead of the 
expanded names (since the entire reason they're behind macros is to prevent the 
use of the 'real' names), though I have no idea how one would even begin to go 
about doing that.

Original issue reported on code.google.com by bunge...@chromium.org on 30 Aug 2014 at 3:27

[GoogleCodeExporter]

Thanks for the report!

This actually seems to work on trunk (yay!):

  $ include-what-you-use.exe -I155 155/use.cpp

  (155/use.cpp has correct #includes/fwd-decls)

> Also, it would be nice if the recommendations used the macro-ized 
> original names instead of the expanded names (since the entire reason 
> they're behind macros is to prevent the use of the 'real' names), 
> though I have no idea how one would even begin to go about doing that.

This is an interesting observation, one we (or at least I) haven't thought of.

I wonder if it always holds that we want to preserve the #include line exactly 
as written...? Especially with macros, they might evaluate to different files 
in different contexts, so when IWYU moves them around things might get chaotic.

We're discussing ways of making the name vs file infrastructure better, and 
this is another good use case that I'd like to address. IWYU currently works 
mostly with include-names and parse them to figure out stuff like "is system 
header? use quotes or angles?", etc. We'd like to have it work with FileEntry 
instances instead so it can make those decisions on firmer grounds. But the 
include-name-as-typed-even-before-macros-expansion might need to be carried 
through anyway.

Original comment by kim.gras...@gmail.com on 30 Aug 2014 at 7:56