[prev in list] [next in list] [prev in thread] [next in thread]
List: cfe-dev
Subject: Re: [cfe-dev] Disable #error?
From: Sean Silva <silvas () purdue ! edu>
Date: 2014-01-15 17:31:46
Message-ID: CAHnXoanS=r4dN4QrRr9kwZhocfCYhWAPjfVkPt-WE6jZ4oQ5kA () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On Wed, Jan 15, 2014 at 12:30 PM, Sean Silva <silvas@purdue.edu> wrote:
>
>
>
> On Wed, Jan 15, 2014 at 1:37 AM, Kim Gr=E4sman <kim.grasman@gmail.com>wro=
te:
>
>> On Tue, Jan 14, 2014 at 11:25 PM, Sean Silva <silvas@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
>>
>
>
[Attachment #5 (text/html)]
<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, \
Jan 15, 2014 at 12:30 PM, Sean Silva <span dir="ltr"><<a \
href="mailto:silvas@purdue.edu" target="_blank">silvas@purdue.edu</a>></span> \
wrote:<br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px \
#ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><br><div \
class="gmail_quote"><div class="im">On Wed, Jan 15, 2014 at 1:37 AM, Kim Gräsman \
<span dir="ltr"><<a href="mailto:kim.grasman@gmail.com" \
target="_blank">kim.grasman@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"><div>On Tue, Jan 14, 2014 at 11:25 PM, Sean Silva <<a \
href="mailto:silvas@purdue.edu" target="_blank">silvas@purdue.edu</a>> wrote:<br>
><br>
> I don't think anyone would be against adding a callback to PPCallbacks \
to<br> > indicate what the error message is so you can get the data. However, \
being<br> > able to affect the outcome of compilation from a PPCallbacks callback \
seems<br> > unwise;<br>
<br>
</div>Yes, I agree that decision does not belong in PPCallbacks. But it's<br>
tempting! :-)<br>
<br>
Actually, now that I think about it, Jacob's scenario is the exact<br>
opposite of mine: he seems to be parsing headers in isolation and I<br>
will always see the private header via its umbrella header.<br>
<br>
For me the #error will never trigger, but that also means I'll never<br>
get a PPCallback for it. I just want to scan for it and use it to<br>
connect the private header name to its \
umbrella.<br></blockquote><div><br></div></div><div>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).</div> \
</div></div></div></blockquote><div><br></div><div>Do'h, I already said that \
upthread....</div><div><br></div><div>-- Sean Silva</div><div> </div><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"> <div dir="ltr"><div class="gmail_extra"><div \
class="gmail_quote"><span class="HOEnZb"><font color="#888888"> \
<div><br></div><div>-- Sean Silva</div></font></span><div class="im"><div> \
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"> <br>
For Jacob it triggers all the time, and he doesn't care about it.<br>
Stripping out the #error before attempting to parse could be a<br>
solution.<br>
<br>
But it would sure be nice to be able to lean on Clang's parser.<br>
<div><br>
> For the purpose of simply collecting #error directives from TU's, it \
seems<br> > like the simplest thing to do would be to use pp-trace (once there is \
a<br> > #error callback in PPCallbacks) driven from a short script. You could \
even<br> > do better than trying to extract the header name from the #error \
message:<br> > just look for the dominating #ifdef and see where it is \
defined.<br> <br>
</div>Good idea, I'll save that for later!<br>
<span><font color="#888888"><br>
- Kim<br>
</font></span></blockquote></div></div><br></div></div>
</blockquote></div><br></div></div>
_______________________________________________
cfe-dev mailing list
cfe-dev@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic