[cfe-dev] math.h on Windows

[John Thompson]

Hi Chris and Doug,

Here's a patch with my initial stab at "__has_include" and
"__has_include_next", along with a test for it (has_include.c) and the
modified stdint.h.

To reuse some code, I had to rearrange things a bit, moving a static
function to Preprocessor, making some Preprocessor functions public, and
adding a couple of accessors.  I also broke out some of the code for
"defined" into a separate function.

The code itself I mostly hacked up from the code for "defined" and
"#include".  This included code for the angle brackets already.  Also,
because "defined" seemed to allow omitting the parentheses, I did it for
"__has_include" and "__has_include_next" also.  The "#include_next" code put
out a warning if the including file was the primary file, so I left this in
for "__has_include_next" also.

A couple of additional things that might need addressing:

Since these are Clang-specific keywords (I think), perhaps they should be
disabled in some circumstances (i.e. language mode), but I'm not sure how,
and I haven't look much into it yet how it is done elsewhere in the code.

Testing the error conditions was a bit tricky as the embedded
"expected-error" annotations affect the preprocessor, and the recovery isn't
always clear.  Also, whether or not to include an "#endif" was unclear.  I
tried the commented-out error conditions in the test, so they minimally seem
to work, but the preprocessor error recovery in general might need some
work. In some cases of including an "#endif" after an error condition, I
would get an assert at PPLexerChange.cpp, line 269.

But if the main code for this is okay, I'd like to check it in, to make it
easier to for me to keep in sync.

-John
On Sun, Oct 25, 2009 at 3:51 PM, Chris Lattner <clattner at apple.com> wrote:

> On Oct 23, 2009, at 11:53 AM, Douglas Gregor wrote:
>
>> On Oct 23, 2009, at 11:48 AM, John Thompson wrote:
>>
>> That (__has_include etc.) sounds good.  I'm assuming that is for use in a
>>> #if?
>>>
>>
>> Yes, just like __has_builtin and __has_feature.
>>
>> It probably makes sense to allow the same forms as include directives,
>> e.g.,
>>
>>        __has_include(<stdlib.h>)
>>        __has_include("stdlib.h")
>>        __has_include_next(<stdlib.h>)
>>        __has_include_next("stdlib.h")
>>
>
> This would be really really really cool.  I'd start with the plain quoted
> version, we can deal with the angled string later, but it will be trickier.
>
> -Chris
>
>


-- 
John Thompson
John.Thompson.JTSoftware at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20091028/b3ad00bf/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hasinclude.patch
Type: application/octet-stream
Size: 19933 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20091028/b3ad00bf/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: has_include.c
Type: application/octet-stream
Size: 2344 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20091028/b3ad00bf/attachment-0001.obj>