[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-14 22:25:09
Message-ID: CAHnXoan7+Q+iJtwyBcg1wBE2vda9U4Htx+rX89T9J9aVpNFQiw () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On Tue, Jan 14, 2014 at 5:14 PM, Kim Gr=E4sman <kim.grasman@gmail.com> wrot=
e:
> That's one way of looking at it.
>
> But we're not really compiling (maybe Jacob is, in some sense); we're
> doing static analysis and the #error directives could give us useful
> data for analysis instead of just aborting.
>
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; it would be kind of like if the #if callback could decide which
branch to take, which means explicitly violating the source code's meaning,
which a compiler shouldn't be doing!
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.
-- Sean Silva
>
> Regex was actually my next plan of attack, we'll see if I ever get
> around to it :-)
>
> - Kim
>
> On Tue, Jan 14, 2014 at 10:58 PM, Sean Silva <silvas@purdue.edu> wrote:
> > Just do:
> >
> > $ sed -i -e 's/#error.*//' **/*.h
> >
> > Really, ignoring the semantics of the program being analyzed (i.e. that
> it
> > requests compilation to be aborted) is just as much of a hack as using
> sed
> > to modify the headers. In both cases, you are forcefully trampling the
> > source code's request.
> >
> > -- Sean Silva
> >
> >
> > On Tue, Jan 14, 2014 at 2:37 PM, Jacob Carlborg <doob@me.com> wrote:
> >>
> >> On 2014-01-14 18:58, Alp Toker wrote:
> >>
> >>> This is an interesting idea. It's always a hard error right now.
> >>>
> >>> We've seen similar requests to 'downgrade' a few other errors like th=
e
> >>> MS inline assembly missing-backend one and I suspect there's a patter=
n
> >>> developing here.
> >>>
> >>> Could you expand on your specific use-case a little?
> >>
> >>
> >> I have a tool that translate C header files to D modules[1]. The tool =
is
> >> designed to translate header files one at the time. The problem is tha=
t
> in
> >> some C libraries some kind of umbrella headers are used. They only
> serve to
> >> include other sub header files. Some of these libraries enforce this b=
y
> the
> >> sub header files checking for a preprocessor macro defined by the
> umbrella
> >> header. If this macro is not defined they halt the complication with t=
he
> >> #error directive.
> >>
> >> I'm using libclang since the tool itself is written in D. D is ABI
> >> compatible with C.
> >>
> >> [1] https://github.com/jacob-carlborg/dstep
> >>
> >> --
> >> /Jacob Carlborg
> >>
> >>
> >> _______________________________________________
> >> cfe-dev mailing list
> >> cfe-dev@cs.uiuc.edu
> >> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
> >
> >
> >
> > _______________________________________________
> > cfe-dev mailing list
> > cfe-dev@cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
> >
>
[Attachment #5 (text/html)]
<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, \
Jan 14, 2014 at 5:14 PM, 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">That's one way of looking at it.<br> <br>
But we're not really compiling (maybe Jacob is, in some sense); we're<br>
doing static analysis and the #error directives could give us useful<br>
data for analysis instead of just aborting.<br></blockquote><div><br></div><div>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; it would be kind of \
like if the #if callback could decide which branch to take, which means explicitly \
violating the source code's meaning, which a compiler shouldn't be \
doing!</div> <div><br></div><div>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.</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"> <br>
Regex was actually my next plan of attack, we'll see if I ever get<br>
around to it :-)<br>
<span class="HOEnZb"><font color="#888888"><br>
- Kim<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
On Tue, Jan 14, 2014 at 10:58 PM, Sean Silva <<a \
href="mailto:silvas@purdue.edu">silvas@purdue.edu</a>> wrote:<br> > Just \
do:<br> ><br>
> $ sed -i -e 's/#error.*//' **/*.h<br>
><br>
> Really, ignoring the semantics of the program being analyzed (i.e. that it<br>
> requests compilation to be aborted) is just as much of a hack as using sed<br>
> to modify the headers. In both cases, you are forcefully trampling the<br>
> source code's request.<br>
><br>
> -- Sean Silva<br>
><br>
><br>
> On Tue, Jan 14, 2014 at 2:37 PM, Jacob Carlborg <<a \
href="mailto:doob@me.com">doob@me.com</a>> wrote:<br> >><br>
>> On 2014-01-14 18:58, Alp Toker wrote:<br>
>><br>
>>> This is an interesting idea. It's always a hard error right now.<br>
>>><br>
>>> We've seen similar requests to 'downgrade' a few other \
errors like the<br> >>> MS inline assembly missing-backend one and I suspect \
there's a pattern<br> >>> developing here.<br>
>>><br>
>>> Could you expand on your specific use-case a little?<br>
>><br>
>><br>
>> I have a tool that translate C header files to D modules[1]. The tool is<br>
>> designed to translate header files one at the time. The problem is that \
in<br> >> some C libraries some kind of umbrella headers are used. They only \
serve to<br> >> include other sub header files. Some of these libraries enforce \
this by the<br> >> sub header files checking for a preprocessor macro defined \
by the umbrella<br> >> header. If this macro is not defined they halt the \
complication with the<br> >> #error directive.<br>
>><br>
>> I'm using libclang since the tool itself is written in D. D is ABI<br>
>> compatible with C.<br>
>><br>
>> [1] <a href="https://github.com/jacob-carlborg/dstep" \
target="_blank">https://github.com/jacob-carlborg/dstep</a><br> >><br>
>> --<br>
>> /Jacob Carlborg<br>
>><br>
>><br>
>> _______________________________________________<br>
>> cfe-dev mailing list<br>
>> <a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>
>> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" \
target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br> ><br>
><br>
><br>
> _______________________________________________<br>
> cfe-dev mailing list<br>
> <a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>
> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" \
target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br> ><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