| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
incompatible with user-defined literals, specifically with the following form:
0x1p+1
The preprocessing-number token extends only as far as the 'p'; the '+' is not
included. Previously we could get away with this extension as p was an invalid
suffix, but now with user-defined literals, 'p' might well be a valid suffix
and we are forced to consider it as such.
This patch also adds a warning in non-0x C++ modes telling the user that
this extension is incompatible with C++0x that is enabled by default
(previously and with other languages, we warn only with a compliance
option such as -pedantic).
llvm-svn: 93135
|
|
|
|
| |
llvm-svn: 93114
|
|
|
|
|
|
| |
nicer than passing around two const char*'s.
llvm-svn: 93094
|
|
|
|
| |
llvm-svn: 93084
|
|
|
|
|
|
|
| |
import other headers within the same framework with the full
framework path, not with a relative include.
llvm-svn: 93083
|
|
|
|
| |
llvm-svn: 93064
|
|
|
|
|
|
|
|
| |
definitions from a precompiled header. This ensures that
code-completion with macro names behaves the same with or without
precompiled headers.
llvm-svn: 92497
|
|
|
|
|
|
| |
termination for us.
llvm-svn: 92358
|
|
|
|
| |
llvm-svn: 92357
|
|
|
|
|
|
| |
this speeds up Eonly on the testcase in PR5888 from 30.5s to 0.85s
llvm-svn: 92203
|
|
|
|
|
|
|
| |
not a token number. Fix the reserve logic to get the right
amount of space.
llvm-svn: 92202
|
|
|
|
| |
llvm-svn: 92127
|
|
|
|
| |
llvm-svn: 92055
|
|
|
|
|
|
|
| |
as a character literal, not a string literal. This might fix
rdar://7486575
llvm-svn: 92025
|
|
|
|
| |
llvm-svn: 91974
|
|
|
|
|
|
|
|
|
| |
1. Don't make a copy of LangOptions every time a lexer is created.
2. Don't make CharInfo global mutable state.
3. Fix the implementation to properly treat ^Z as EOF instead of as
horizontal whitespace, which matches the semantic implemented by VC++.
llvm-svn: 91586
|
|
|
|
|
|
|
|
|
|
| |
on PR5610 (2.185 -> 2.130s). The big issue is that this is making
insanely huge macro argument lists with over a million tokens in it.
The reason that mallco and free are so expensive is that we are
actually going to the kernel to get it, and switching to a bump
pointer allocator won't change this in an interesting way.
llvm-svn: 91449
|
|
|
|
|
|
|
|
|
| |
We creating and free thousands of MacroArgs objects (and the related
std::vectors hanging off them) for the testcase in PR5610 even though
there are only ~20 live at a time. This doesn't actually use the
cache yet.
llvm-svn: 91391
|
|
|
|
|
|
|
| |
on 64-bit targets. Pass Preprocessor into create/destroy methods of MacroArgs
even though it isn't used yet.
llvm-svn: 91345
|
|
|
|
| |
llvm-svn: 91343
|
|
|
|
|
|
| |
files: PR5238.
llvm-svn: 91270
|
|
|
|
|
|
|
|
| |
expanding directives withing macro expansions. This is undefined behavior
according to 6.10.3p11, so we might as well be undefined in ways similar to
GCC.
llvm-svn: 91266
|
|
|
|
| |
llvm-svn: 91263
|
|
|
|
| |
llvm-svn: 91262
|
|
|
|
| |
llvm-svn: 90881
|
|
|
|
|
|
| |
http://llvm.org/viewvc/llvm-project?view=rev&revision=80043
llvm-svn: 90860
|
|
|
|
|
|
|
| |
diagnostics (specifically, that any extension in a compiler-reserved namespace
shouldn't trigger a diagnostic).
llvm-svn: 90826
|
|
|
|
|
|
|
|
| |
expected to fail.
Also, update SourceManager.h doxyments for getBuffer() to reflect reality.
llvm-svn: 90701
|
|
|
|
|
|
| |
should be forced to deal with error conditions.
llvm-svn: 90700
|
|
|
|
| |
llvm-svn: 90543
|
|
|
|
| |
llvm-svn: 90459
|
|
|
|
|
|
| |
preprocessor logic if C++ exceptions are enabled.
llvm-svn: 90378
|
|
|
|
| |
llvm-svn: 90376
|
|
|
|
| |
llvm-svn: 90368
|
|
|
|
|
|
|
|
|
|
| |
files with the contents of an arbitrary memory buffer. Use this new
functionality to drastically clean up the way in which we handle file
truncation for code-completion: all of the truncation/completion logic
is now encapsulated in the preprocessor where it belongs
(<rdar://problem/7434737>).
llvm-svn: 90300
|
|
|
|
|
|
|
|
|
|
|
|
| |
in diagnostics when we fail to open a file. This allows us to
report things like:
$ clang test.c -I.
test.c:2:10: fatal error: error opening file './foo.h': Permission denied
#include "foo.h"
^
llvm-svn: 90276
|
|
|
|
|
|
|
|
|
|
| |
stat a file but where mmaping it fails. In this case, we emit an
error like:
t.c:1:10: fatal error: error opening file '../../foo.h'
instead of "cannot find file".
llvm-svn: 90110
|
|
|
|
| |
llvm-svn: 90080
|
|
|
|
| |
llvm-svn: 90044
|
|
|
|
| |
llvm-svn: 90040
|
|
|
|
|
|
| |
btw, I believe that isMicrosoftInteger can go away; it's not read anywhere
llvm-svn: 90036
|
|
|
|
|
|
| |
Amine Khaldi!
llvm-svn: 88797
|
|
|
|
| |
llvm-svn: 88732
|
|
|
|
| |
llvm-svn: 87087
|
|
|
|
|
|
| |
Also, always give errors on a token-cache PTH failure.
llvm-svn: 86939
|
|
|
|
|
|
|
|
|
|
|
| |
annotation token, because some of the tokens we're annotating might
not be in the set of cached tokens (we could have consumed them
unconditionally).
Also, move the tentative parsing from ParseTemplateTemplateArgument
into the one caller that needs it, improving recovery.
llvm-svn: 86904
|
|
|
|
|
|
| |
should probably always own the header search object, but I'm not sure...
llvm-svn: 86882
|
|
|
|
| |
llvm-svn: 86760
|
|
|
|
|
|
|
|
|
| |
a little fuzzy, but conceptually it's just uniquing the identifier.
Chris, please review. I debated splitting into const/non-const versions where
the const one propogated constness to the resulting IdentifierInfo*.
llvm-svn: 86106
|
|
|
|
| |
llvm-svn: 86105
|