buffer. This caused exciting nonsense like this:
$ clang t.c -fsyntax-only -UMACRO
In file included from <built-in>:104:
<command line>:1:14: warning: extra tokens at end of #undef directive [-Wextra-tokens]
#undef MACRO 1
^
//
1 diagnostic generated.
rdar://6891800
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@71860 91177308-0d34-0410-b5e6-96231b3b80d8
- If we don't find a file looking relative to the current working
directory, fall back to header search. This is closer to what would
happen if the lookup was starting from right directory in the first
place (except it will find files in the directory of the main
source file, which I *think* should not be found).
- PR3992.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@69794 91177308-0d34-0410-b5e6-96231b3b80d8
by marking the predefines buffer as a system header. The problem
with stdint is that it was getting problems like this:
/Volumes/Projects/cvs/llvm/Debug/lib/clang/1.0/include/stdint.h:43:9: warning: 'long long' is an extension when C99 mode is not enabled
typedef __INT64_TYPE__ int64_t;
^
<built-in>:73:29: note: instantiated from:
#define __INT64_TYPE__ long long
^
We correctly silence warnings in system headers, but only if the
spelling location of the token came from the system header. This is
designed so that if you use a system macro in your code that you don't
get punished for its definition. This is all cool except that the
predefines buffer wasn't considered a system header.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@69770 91177308-0d34-0410-b5e6-96231b3b80d8
Eli Friedman