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

Literal value calculation isn't likely to overflow on targets having int as 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

Implement UCN support for C string literals (C99 6.4.3) and add some very basic tests. Chris Goller has graciously offered to write some test to help validate UCN support.

From a front-end perspective, I believe this code should work for ObjC @-strings. At the moment, I believe we need to tweak the code generation for @-strings (which doesn't appear to handle them). Will be investigating.

llvm-svn: 68076

llvm-svn: 65582

escapes in the string for subtoken positioning.  This gives
us working examples like:

t.m:5:16: warning: field width should have type 'int', but argument has type 'unsigned int'
  printf("\n\n%*d", (unsigned) 1, 1);
               ^    ~~~~~~~~~~~~

where before the caret pointed two spaces to the left.

llvm-svn: 64940

redundant #includes.  Patch by Anders Johnsen!

llvm-svn: 63271

.def file for each library.  This means that adding a diagnostic
to sema doesn't require all the other libraries to be rebuilt.

Patch by Anders Johnsen!

llvm-svn: 63111

into its ctor.  Also, make it handle validity checking of pascal
strings instead of making clients do it.

llvm-svn: 62332

would not eat the "-1" in "0x0p-1", but LiteralSupport would accept
it when extensions are on.  This caused strangeness and failures 
when hexfloats were properly treated as an extension (not error)
in LiteralSupport.

llvm-svn: 59865

its call sites.  This makes it more explicit when the hasError flag is
getting set and removes a confusing difference in behavior between
PP.Diag and Diag in this code.

llvm-svn: 59863

llvm-svn: 59554

 - Implement fast path when value easily fits in a uint64.
 - ~6x faster, translates to 1-2% on Cocoa.h

llvm-svn: 57632

llvm-svn: 57629

llvm-svn: 56876

NumericLiteral parser is not careful about overrun because
it should never be possible.  It implicitly expects that its
input matched the regex for pp-constant.  Because of this, it
knows it can't be pointing to a prefix of something that
looks like a number.  This is all fine, except that __LINE__
does not prevent implicit concatenation from happening.  Fix
__LINE__ to not do this.

llvm-svn: 56818

Note that this isn't really a complete fix; I think there are other 
potential overrun situations.  I don't really know what the best 
systematic fix is, though.

llvm-svn: 55622

 - Kill unnecessary #includes in .cpp files. This is an automatic
   sweep so some things removed are actually used, but happen to be
   included by a previous header. I tried to get rid of the obvious
   examples and this was the easiest way to trim the #includes in one
   fell swoop.
 - We now return to regularly scheduled development.

llvm-svn: 54632

t2.c:1:17: warning: hexadecimal floating constants are a C99 feature
long double d = 0x0.0000003ffffffff00000p-16357L;
                ^

instead of emitting a weird error message that doesn't make sense:

t2.c:1:41: error: hexadecimal floating constants require an exponent
long double d = 0x0.0000003ffffffff00000p-16357L;
                                        ^

rdar://6096838

llvm-svn: 54035

rejected FP immediates like 08.123

llvm-svn: 52890

llvm-svn: 52889

llvm-svn: 49997

literal, indicate what character the error is about or where
it would be.  For example:

pr2241.c:1:17: error: exponent has no digits
float f[] = { 1e  , 1ee0 };
                ^

llvm-svn: 49996

llvm-svn: 49229

lib dir and move all the libraries into it.  This follows the main
llvm tree, and allows the libraries to be built in parallel.  The
top level now enforces that all the libs are built before Driver,
but we don't care what order the libs are built in.  This speeds
up parallel builds, particularly incremental ones.

llvm-svn: 48402

llvm-svn: 47954