[cfe-dev] Disable #error?

Sean Silva silvas at purdue.edu
Tue Jan 14 14:25:09 PST 2014


On Tue, Jan 14, 2014 at 5:14 PM, Kim Gräsman <kim.grasman at gmail.com> wrote:

> 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 at 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 at 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 at cs.uiuc.edu
> >> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
> >
> >
> >
> > _______________________________________________
> > cfe-dev mailing list
> > cfe-dev at cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20140114/0596a4de/attachment.html>


More information about the cfe-dev mailing list