<div>Hi Chris and Doug,</div>
<div> </div>
<div>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.</div>
<div> </div>
<div>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.</div>

<div> </div>
<div>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.</div>

<div> </div>
<div>A couple of additional things that might need addressing:</div>
<div> </div>
<div>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.</div>

<div> </div>
<div>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.</div>

<div> </div>
<div>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.</div>
<div> </div>
<div>-John<br></div>
<div class="gmail_quote">On Sun, Oct 25, 2009 at 3:51 PM, Chris Lattner <span dir="ltr"><<a href="mailto:clattner@apple.com">clattner@apple.com</a>></span> wrote:<br>
<blockquote style="BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex; PADDING-LEFT: 1ex" class="gmail_quote">
<div class="im">On Oct 23, 2009, at 11:53 AM, Douglas Gregor wrote:<br>
<blockquote style="BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex; PADDING-LEFT: 1ex" class="gmail_quote">On Oct 23, 2009, at 11:48 AM, John Thompson wrote:<br><br>
<blockquote style="BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex; PADDING-LEFT: 1ex" class="gmail_quote">That (__has_include etc.) sounds good.  I'm assuming that is for use in a #if?<br></blockquote><br>Yes, just like __has_builtin and __has_feature.<br>
<br>It probably makes sense to allow the same forms as include directives, e.g.,<br><br>       __has_include(<stdlib.h>)<br>       __has_include("stdlib.h")<br>       __has_include_next(<stdlib.h>)<br>
       __has_include_next("stdlib.h")<br></blockquote><br></div>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.<br>
<font color="#888888"><br>-Chris<br><br></font></blockquote></div><br><br clear="all"><br>-- <br>John Thompson<br><a href="mailto:John.Thompson.JTSoftware@gmail.com">John.Thompson.JTSoftware@gmail.com</a><br><br>