[cfe-dev] Disable #error?

[Sean Silva]

On Wed, Jan 15, 2014 at 2:38 PM, Jacob Carlborg <doob at me.com> wrote:

> On 2014-01-15 18:39, Sean Silva wrote:
>
>  You are trying to understand the meaning of the program, which means
>> that you are under the same correctness constraints as when compiling.
>>
>
> I want the tool to understand enough to do the translation.
>
>
>  Consider:
>>
>> #if defined(FOO)
>> #error "bar"
>> void
>> #else
>> int
>> #endif
>> some_function(int arg);
>>
>> If you ignore the #error, you will misunderstand the program's semantics.
>>
>
> I do understand what you're saying but I don't see any other way.


The cleanest thing in your particular usecase is to just ignore that header
if you hit that sort of #error, since you will end up including it through
it's "proper" user-facing header when processing a different header. Or is
there some impediment to doing that?

Otherwise, it's really a discussion about "where do we put in a gross hack
to trample the source code's intent and forcibly ignore the check and
#error". That gross hack could be in clang, it could be done by sed, it
could be done in memory on the file buffers, it could be done by detecting
such errors and reparsing with -D__INCLUDED_UMBRELLA_H (or whatever the
guard macro is), or any of a number of techniques. Without a really
compelling use case, my gut is to not want that hack to live in clang.

-- Sean Silva


> The feature would probably be off by default with a flag to enable it. The
> user is free to use it if he/she wants to.
>
>
> --
> /Jacob Carlborg
>
> _______________________________________________
> 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/20140115/04143b16/attachment.html>