[cfe-commits] [PATCH] Disallow __has_include and __has_include_next outside of preprocessor directives

[Aaron Ballman]

This patch moves the logic around slightly to handle macros better;
instead of relying on the PP Lexer, we track the information in the PP
itself so that is is always available.  I've expanded the test cases
to cover macros more fully.

Thanks!

~Aaron

On Tue, Jan 15, 2013 at 7:52 PM, Aaron Ballman <aaron at aaronballman.com> wrote:
> As far as I can tell, the only way to handle that case would be to
> track whether we're in a preprocessor directive as part of
> Preprocessor's state instead of just PreprocessorLexer.  Unless
> someone sees another way that I'm not familiar with?
>
> ~Aaron
>
> On Tue, Jan 15, 2013 at 7:13 PM, Aaron Ballman <aaron at aaronballman.com> wrote:
>> Unfortunately, we can't.  Consider:
>>
>> #define MACRO1 __has_include(<stdint.h>)
>>
>> #if !MACRO1
>>   #error "__has_include with macro failed (1)."
>> #endif
>>
>> However, my patch doesn't address the usage of macros.  I'll explore a
>> bit to see if there's something more I can do in that case.
>>
>> ~Aaron
>>
>> On Tue, Jan 15, 2013 at 6:58 PM, Dmitri Gribenko <gribozavr at gmail.com> wrote:
>>> On Wed, Jan 16, 2013 at 1:49 AM, Aaron Ballman <aaron at aaronballman.com> wrote:
>>>> 3 -- if there's not a current lexer, we have no way to know we're
>>>> currently in a preprocessor directive (that I'm aware of).
>>>
>>> Is there a case where we use this mode to parse a pp directive?  Can
>>> we always emit an error in this case?
>>>
>>> Dmitri
>>>
>>> --
>>> main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
>>> (j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr at gmail.com>*/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pr14837.patch
Type: application/octet-stream
Size: 5783 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130116/efe54018/attachment.obj>