| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
| |
LLVM.h imports
them into the clang namespace.
llvm-svn: 135852
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
1. We would assume that the length of the string literal token was at least 2
2. We would allocate a buffer with size length-2
And when the stars aligned (one of which would be an invalid source location due to stale PCH)
The length would be 0 and we would try to allocate a 4GB buffer.
Add checks for this corner case and a bunch of asserts.
(We really really should have had an assert for 1.).
Note that there's no test case since I couldn't get one (it was major PITA to reproduce),
maybe later.
llvm-svn: 131492
|
|
|
|
|
|
| |
Luis Felipe Strano Moraes!
llvm-svn: 129559
|
|
|
|
|
|
|
|
|
| |
i64 is like LL
i32 is like L
Also set isMicrosoftInteger to true only if the suffix is well formed.
llvm-svn: 123230
|
|
|
|
|
|
| |
Patch by Paul Curtis!
llvm-svn: 120759
|
|
|
|
|
|
| |
related to.
llvm-svn: 119479
|
|
|
|
|
|
| |
possible to create one without a preprocessor.
llvm-svn: 119476
|
|
|
|
| |
llvm-svn: 119475
|
|
|
|
|
|
| |
Preprocessor to Lexer where they make more sense.
llvm-svn: 119474
|
|
|
|
| |
llvm-svn: 119472
|
|
|
|
| |
llvm-svn: 119471
|
|
|
|
| |
llvm-svn: 119470
|
|
|
|
| |
llvm-svn: 119469
|
|
|
|
|
|
| |
pushing the dependency on the preprocessor out a bit.
llvm-svn: 119468
|
|
|
|
|
|
| |
by Martin Vejnar!
llvm-svn: 116460
|
|
|
|
| |
llvm-svn: 116129
|
|
|
|
| |
llvm-svn: 115743
|
|
|
|
| |
llvm-svn: 112680
|
|
|
|
|
|
| |
in wide strings. radar 8360841.
llvm-svn: 112672
|
|
|
|
|
|
| |
some issues being sorted out.
llvm-svn: 112493
|
|
|
|
|
|
|
|
|
|
| |
The extra data stored on user-defined literal Tokens is stored in extra
allocated memory, which is managed by the PreprocessorLexer because there isn't
a better place to put it that makes sure it gets deallocated, but only after
it's used up. My testing has shown no significant slowdown as a result, but
independent testing would be appreciated.
llvm-svn: 112458
|
|
|
|
| |
llvm-svn: 110807
|
|
|
|
|
|
| |
standard's minimum requirements.
llvm-svn: 108837
|
|
|
|
|
|
|
|
|
|
| |
Fix string concatenation to treat escapes in concatenated strings that
are wide because of other string chunks to process the escapes as wide
themselves. Before we would warn about and miscompile the attached testcase.
This fixes rdar://8040728 - miscompile + warning: hex escape sequence out of range
llvm-svn: 106012
|
|
|
|
|
|
| |
(radar 8020384)
llvm-svn: 104996
|
|
|
|
|
|
|
|
| |
diagnostics. That would be while we're parsing string literals for the
sole purpose of producing a diagnostic about them. Fixes
<rdar://problem/8026030>.
llvm-svn: 104684
|
|
|
|
| |
llvm-svn: 101580
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
SourceManager's getBuffer() and, therefore, could fail, along with
Preprocessor::getSpelling(). Use the Invalid parameters in the literal
parsers (string, floating point, integral, character) to make them
robust against errors that stem from, e.g., PCH files that are not
consistent with the underlying file system.
I still need to audit every use caller to all of these routines, to
determine which ones need specific handling of error conditions.
llvm-svn: 98608
|
|
|
|
|
|
| |
Fixes radar 7562363.
llvm-svn: 94224
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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: 92127
|
|
|
|
| |
llvm-svn: 91974
|
|
|
|
|
|
| |
btw, I believe that isMicrosoftInteger can go away; it's not read anywhere
llvm-svn: 90036
|
|
|
|
|
|
|
| |
to add a flag noting the presence of a Microsoft extension suffix (i8,
i16, i32, i64). Patch by John Thompson.
llvm-svn: 83591
|
|
|
|
| |
llvm-svn: 81346
|
|
|
|
| |
llvm-svn: 79211
|
|
|
|
| |
llvm-svn: 77420
|
|
|
|
| |
llvm-svn: 75627
|
|
|
|
| |
llvm-svn: 73153
|
|
|
|
| |
llvm-svn: 72928
|
|
|
|
|
|
| |
preprocessor.
llvm-svn: 72686
|
|
|
|
|
|
| |
and apparently not part of -Wall
llvm-svn: 70329
|
|
|
|
| |
llvm-svn: 70315
|
|
|
|
|
|
|
|
|
|
|
|
| |
that if we're going to print an extension warning anyway,
there's no point to changing behavior based on NoExtensions: it will
only make error recovery worse.
Note that this doesn't cause any behavior change because NoExtensions
isn't used by the current front-end. I'm still considering what to do about
the remaining use of NoExtensions in IdentifierTable.cpp.
llvm-svn: 70273
|
|
|
|
|
|
| |
So 'abc' on i16 platforms will warn but not on i32 platforms.
llvm-svn: 69653
|
|
|
|
| |
llvm-svn: 69054
|
|
|
|
|
|
| |
32 or less. Fixing the assert as it otherwise triggers for PIC16 which as i16 as int.
llvm-svn: 69046
|
|
|
|
| |
llvm-svn: 68198
|
|
|
|
| |
llvm-svn: 68181
|
|
|
|
| |
llvm-svn: 68107
|