[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:47:11
Message-ID: CAHnXoanobVQjqRPp3aXzs3K4FmS1f6L0tw8_cp84be98gGhTsw () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On Wed, Jan 15, 2014 at 7:54 AM, Alp Toker <alp@nuanti.com> wrote:
>
> On 14/01/2014 21:58, Sean Silva 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.
>>
>
> Hi Sean,
>
> The use case for 'softer' errors is source transformation and tooling,
> where the directives aren't meant to be evaluated in the first place.
> Without evaluation, there is no request to trample on.
>
> There's certainly a class of syntactic errors that we could recover from
> more gracefully to enable safe refactoring of incomplete translation units.
>
I assume that "safe refactoring" means "respects the source code's
meaning". Code that has a syntactic error has no defined meaning and
therefore by definition cannot be refactored in a "safe" manner. Any such
approach will be purely heuristic.
-- Sean Silva
>
> What's clear is that sed isn't a viable part of that tooling. The whole
> aim is to offer a clean semantic interface to analyse and manipulate user
> code -- and in that context the original source tree is always immutable.
>
> So let's hear out the user requests -- there's something to these but I'm
> not sure quite what it is yet.
>
> Alp.
>
>
>
>> -- Sean Silva
>>
>>
>>
>> On Tue, Jan 14, 2014 at 2:37 PM, Jacob Carlborg <doob@me.com <mailto:
>> 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 the
>> MS inline assembly missing-backend one and I suspect there's a
>> pattern
>> 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 that 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 by 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 the #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 <mailto: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
>>
>
> --
> http://www.nuanti.com
> the browser experts
>
>
[Attachment #5 (text/html)]
<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, \
Jan 15, 2014 at 7:54 AM, Alp Toker <span dir="ltr"><<a \
href="mailto:alp@nuanti.com" target="_blank">alp@nuanti.com</a>></span> wrote:<br> \
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"><div class="im"><br> On 14/01/2014 21:58, Sean Silva \
wrote:<br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px \
#ccc solid;padding-left:1ex"> 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 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.<br>
</blockquote>
<br></div>
Hi Sean,<br>
<br>
The use case for 'softer' errors is source transformation and tooling, where \
the directives aren't meant to be evaluated in the first place. Without \
evaluation, there is no request to trample on.<br> <br>
There's certainly a class of syntactic errors that we could recover from more \
gracefully to enable safe refactoring of incomplete translation \
units.<br></blockquote><div><br></div><div>I assume that "safe refactoring" \
means "respects the source code's meaning". Code that has a syntactic \
error has no defined meaning and therefore by definition cannot be refactored in a \
"safe" manner. Any such approach will be purely heuristic.</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>
What's clear is that sed isn't a viable part of that tooling. The whole aim \
is to offer a clean semantic interface to analyse and manipulate user code -- and in \
that context the original source tree is always immutable.<br>
<br>
So let's hear out the user requests -- there's something to these but I'm \
not sure quite what it is yet.<br> <br>
Alp.<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"> <br>
-- Sean Silva<div class="im"><br>
<br>
<br>
On Tue, Jan 14, 2014 at 2:37 PM, Jacob Carlborg <<a href="mailto:doob@me.com" \
target="_blank">doob@me.com</a> <mailto:<a href="mailto:doob@me.com" \
target="_blank">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<br>
like the<br>
MS inline assembly missing-backend one and I suspect there's a<br>
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<br>
tool is designed to translate header files one at the time. The<br>
problem is that in some C libraries some kind of umbrella headers<br>
are used. They only serve to include other sub header files. Some<br>
of these libraries enforce this by the sub header files checking<br>
for a preprocessor macro defined by the umbrella header. If this<br>
macro is not defined they halt the complication with the #error<br>
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-<u></u>carlborg/dstep</a><br> <br>
-- /Jacob Carlborg<br>
<br>
<br>
______________________________<u></u>_________________<br>
cfe-dev mailing list<br></div>
<a href="mailto:cfe-dev@cs.uiuc.edu" target="_blank">cfe-dev@cs.uiuc.edu</a> \
<mailto:<a href="mailto:cfe-dev@cs.uiuc.edu" \
target="_blank">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/<u></u>mailman/listinfo/cfe-dev</a><div \
class="im"><br> <br>
<br>
<br>
<br>
______________________________<u></u>_________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@cs.uiuc.edu" target="_blank">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/<u></u>mailman/listinfo/cfe-dev</a><br> \
</div></blockquote> <br><div class="HOEnZb"><div class="h5">
-- <br>
<a href="http://www.nuanti.com" target="_blank">http://www.nuanti.com</a><br>
the browser experts<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