Make __has_include a bit more resilient in the presence of macros. <rdar://problem/12748859>.

llvm-svn: 171939
This commit is contained in:
Eli Friedman
2013-01-09 02:20:00 +00:00
parent 0657b40b3c
commit ec94b61745
2 changed files with 35 additions and 2 deletions

View File

@@ -985,8 +985,14 @@ static bool EvaluateHasIncludeCommon(Token &Tok,
// Save '(' location for possible missing ')' message.
LParenLoc = Tok.getLocation();
// Get the file name.
PP.getCurrentLexer()->LexIncludeFilename(Tok);
if (PP.getCurrentLexer()) {
// Get the file name.
PP.getCurrentLexer()->LexIncludeFilename(Tok);
} else {
// We're in a macro, so we can't use LexIncludeFilename; just
// grab the next token.
PP.Lex(Tok);
}
}
// Reserve a buffer to get the spelling.

View File

@@ -64,6 +64,33 @@
#error "defined(__has_include_next) failed (8)."
#endif
// Fun with macros
#define MACRO1 __has_include(<stdint.h>)
#define MACRO2 ("stdint.h")
#define MACRO3 ("blahblah.h")
#define MACRO4 blahblah.h>)
#define MACRO5 <stdint.h>
#if !MACRO1
#error "__has_include with macro failed (1)."
#endif
#if !__has_include MACRO2
#error "__has_include with macro failed (2)."
#endif
#if __has_include MACRO3
#error "__has_include with macro failed (3)."
#endif
#if __has_include(<MACRO4
#error "__has_include with macro failed (4)."
#endif
#if !__has_include(MACRO5)
#error "__has_include with macro failed (2)."
#endif
// Try badly formed expressions.
// FIXME: We can recover better in almost all of these cases. (PR13335)