| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
| |
*end* of a macro instantiation, not the start of it. This is
really all about bug-for-bug compatibility with GCC, but not
doing this breaks the FreeBSD kernel.
llvm-svn: 64603
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Now instead of just tracking the expansion history, also track the full
range of the macro that got replaced. For object-like macros, this doesn't
change anything. For _Pragma and function-like macros, this means we track
the locations of the ')'.
This is required for PR3579 because apparently GCC uses the line of the ')'
of a function-like macro as the location to expand __LINE__ to.
llvm-svn: 64601
|
| |
|
|
|
|
|
|
|
| |
_GCC_LIMITS_H_ is defined, when __GNUC__ is defined.
Also, we need to stay away from possible conflicts with header guards.
We should use CLANG_ to prefix all header guards.
llvm-svn: 64408
|
| |
|
|
|
|
|
| |
diffing the output of:
clang -dM -o - -E -x c foo.c | sort
llvm-svn: 63926
|
| |
|
|
| |
llvm-svn: 63766
|
| |
|
|
|
|
| |
buffer as if the #include happened from the main file.
llvm-svn: 63764
|
| |
|
|
|
|
| |
directory as well as from the pp directory.
llvm-svn: 63763
|
| |
|
|
| |
llvm-svn: 63762
|
| |
|
|
| |
llvm-svn: 63761
|
| |
|
|
| |
llvm-svn: 63759
|
| |
|
|
| |
llvm-svn: 63758
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
line markers, including maintenance of the virtual include stack.
For something like this:
# 42 "bar.c" 1
# 142 "bar2.c" 1
#warning zappa
# 92 "bar.c" 2
#warning gonzo
# 102 "foo.c" 2
#warning bonkta
we now produce these three warnings:
#1:
In file included from foo.c:3:
In file included from bar.c:42:
bar2.c:143:2: warning: #warning zappa
#warning zappa
^
#2:
In file included from foo.c:3:
bar.c:92:2: warning: #warning gonzo
#warning gonzo
^
#3:
foo.c:102:2: warning: #warning bonkta
#warning bonkta
^
llvm-svn: 63722
|
| |
|
|
| |
llvm-svn: 63721
|
| |
|
|
|
|
| |
play around with the 'is system header' bit now function correctly.
llvm-svn: 63720
|
| |
|
|
| |
llvm-svn: 63713
|
| |
|
|
| |
llvm-svn: 63407
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
as reported to the user and as manipulated by #line. This is what __FILE__,
__INCLUDE_LEVEL__, diagnostics and other things should follow (but not
dependency generation!).
This patch also includes several cleanups along the way:
- SourceLocation now has a dump method, and several other places
that did similar things now use it.
- I cleaned up some code in AnalysisConsumer, but it should probably be
simplified further now that NamedDecl is better.
- TextDiagnosticPrinter is now simplified and cleaned up a bit.
This patch is a prerequisite for #line, but does not actually provide
any #line functionality.
llvm-svn: 63098
|
| |
|
|
| |
llvm-svn: 63094
|
| |
|
|
| |
llvm-svn: 63003
|
| |
|
|
| |
llvm-svn: 63001
|
| |
|
|
|
|
| |
we just discard them.
llvm-svn: 62999
|
| |
|
|
|
|
| |
Anders noticed.
llvm-svn: 62472
|
| |
|
|
| |
llvm-svn: 62339
|
| |
|
|
|
|
|
|
|
|
| |
documented here:
http://msdn.microsoft.com/en-us/library/7f0aews7(VS.80).aspx
This is according to my understanding reading the docs, I don't know if it
really agrees fully with what VC++ allows.
llvm-svn: 62317
|
| |
|
|
|
|
|
| |
the "physical" location of tokens, refer to the "spelling" location.
This is more concrete and useful, tokens aren't really physical objects!
llvm-svn: 62309
|
| |
|
|
| |
llvm-svn: 60363
|
| |
|
|
| |
llvm-svn: 59794
|
| |
|
|
| |
llvm-svn: 59539
|
| |
|
|
| |
llvm-svn: 59537
|
| |
|
|
| |
llvm-svn: 59534
|
| |
|
|
| |
llvm-svn: 58291
|
| |
|
|
|
|
| |
Rename -dumptokens to -dump-tokens.
llvm-svn: 57405
|
| |
|
|
| |
llvm-svn: 57068
|
| |
|
|
| |
llvm-svn: 56670
|
| |
|
|
|
|
| |
- Replace FIXME in Preprocessor::HandleIdentifier() with a check that avoids diagnosing extension tokens that originate from macro definitions.
llvm-svn: 55639
|
| |
|
|
|
|
| |
somewhere else in the path. fix that.
llvm-svn: 55175
|
| |
|
|
| |
llvm-svn: 53802
|
| |
|
|
|
|
|
| |
"When dumping the tokens (-dumptokens output type), the column numbers are not
correctly shown. This patch fixes that issue."
llvm-svn: 53797
|
| |
|
|
|
|
| |
Otherwise, failing tests other than the last one will not be reported.
llvm-svn: 52231
|
| |
|
|
|
|
|
| |
__VA_ARGS__ syntax as well as with the amazingly awesome GNU "named
variadic macro" extension. Allow it with the GNU syntax as well.
llvm-svn: 50843
|
| |
|
|
|
|
| |
think it is really right. :) This fixes PR2284.
llvm-svn: 50665
|
| |
|
|
|
|
| |
the final part of PR2279
llvm-svn: 50635
|
| |
|
|
|
|
|
|
|
| |
a) correct rejection of ',' in pp expressions.
b) the precedence of ',' was wrong w.r.t. ?:.
Thanks again to Neil for finding these and providing testcases.
llvm-svn: 50625
|
| |
|
|
|
|
| |
for pointing this out.
llvm-svn: 50624
|
| |
|
|
| |
llvm-svn: 50617
|
| |
|
|
|
|
| |
more nice.
llvm-svn: 49619
|
| |
|
|
| |
llvm-svn: 48668
|
| |
|
|
|
|
| |
the output to make sure that the macros and comments are being treated as such.
llvm-svn: 48638
|
| |
|
|
|
|
| |
required to perform this test.
llvm-svn: 48636
|
| |
|
|
|
|
| |
removal.
llvm-svn: 47986
|