[cfe-dev] Disable #error?

[Kim Gräsman]

On Tue, Jan 14, 2014 at 11:25 PM, Sean Silva <silvas at purdue.edu> wrote:
>
> I don't think anyone would be against adding a callback to PPCallbacks to
> indicate what the error message is so you can get the data. However, being
> able to affect the outcome of compilation from a PPCallbacks callback seems
> unwise;

Yes, I agree that decision does not belong in PPCallbacks. But it's
tempting! :-)

Actually, now that I think about it, Jacob's scenario is the exact
opposite of mine: he seems to be parsing headers in isolation and I
will always see the private header via its umbrella header.

For me the #error will never trigger, but that also means I'll never
get a PPCallback for it. I just want to scan for it and use it to
connect the private header name to its umbrella.

For Jacob it triggers all the time, and he doesn't care about it.
Stripping out the #error before attempting to parse could be a
solution.

But it would sure be nice to be able to lean on Clang's parser.

> For the purpose of simply collecting #error directives from TU's, it seems
> like the simplest thing to do would be to use pp-trace (once there is a
> #error callback in PPCallbacks) driven from a short script. You could even
> do better than trying to extract the header name from the #error message:
> just look for the dominating #ifdef and see where it is defined.

Good idea, I'll save that for later!

- Kim