[cfe-dev] Disable #error?

[Sean Silva]

On Wed, Jan 15, 2014 at 12:30 PM, Sean Silva <silvas at purdue.edu> wrote:

>
>
>
> On Wed, Jan 15, 2014 at 1:37 AM, Kim Gräsman <kim.grasman at gmail.com>wrote:
>
>> 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.
>>
>
> Just use pp-trace on the lone header and pipe it into a 10-line Python
> script. (once a #error callback is introduced in PPCallbacks, and it is
> wired into pp-trace).
>

Do'h, I already said that upthread....

-- Sean Silva


>
> -- Sean Silva
>
>
>>
>> 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
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20140115/8996348e/attachment.html>