llvm-svn: 174814

Add warnings under -Wc++11-compat, -Wc++98-compat, and -Wc99-compat when a
particular UCN is incompatible with a different standard, and -Wunicode when
a UCN refers to a surrogate character in C++03.

llvm-svn: 174788

I threw in a couple of test cases for UD-suffixes -- already working, but
it wasn't immediately obvious to me.

llvm-svn: 174767

llvm-svn: 174215

The a2q core is the variant of the a2 core used on the BG/Q supercomputers.

llvm-svn: 174151

In cooperation with the LLVM patch, this should implement all scalar front-end
parts of the C and C++ ABIs for AArch64.

This patch excludes the NEON support also reviewed due to an outbreak of
batshit insanity in our legal department. That will be committed soon bringing
the changes to precisely what has been approved.

Further reviews would be gratefully received.

llvm-svn: 174055

  #define X X

for which there is no point warning, ever.

llvm-svn: 173991

This reverts commit r173952

llvm-svn: 173970

for "#define X X".

This is a pattern that, for example, stdbool.h uses.
rdar://12435773

llvm-svn: 173952

if they were already concatenated in source using the spelling locations
even if they came from a macro expansion.

This fixes an issue where a GUID passed as macro argument ends up
malformed after preprocessing because we added spaces inside it.

rdar://13016645

llvm-svn: 173826

llvm-svn: 173720

llvm-svn: 173717

llvm-svn: 173716

llvm-svn: 173697

The -E output from clang did not produce the correct indentation on the first line.
This is because MoveToLine returned false, and when this happens,
the regular process for producing initial indentation is skipped.

Thanks to Eli for suggesting a way to simplify this to a one-line change.

llvm-svn: 173657

llvm-svn: 173582

You may see such a message on non-posix system;
  ignoring nonexistent directory "/usr/local/include"
  ignoring nonexistent directory "/usr/include"

llvm-svn: 173525

llvm-svn: 173484

llvm-svn: 173482

llvm-svn: 173469

 - This just scratches the surface, We have pretty horrible test coverage in
   this area it seems like, but this at least covers the change in r173410.

llvm-svn: 173464

Also, remove stray -fdiagnostics-parseable-fixits from ucn-pp-identifier.

llvm-svn: 173373

llvm-svn: 173371

This is a missing piece for C99 conformance.

This patch handles UCNs by adding a '\\' case to LexTokenInternal and
LexIdentifier -- if we see a backslash, we tentatively try to read in a UCN.
If the UCN is not syntactically well-formed, we fall back to the old
treatment: a backslash followed by an identifier beginning with 'u' (or 'U').

Because the spelling of an identifier with UCNs still has the UCN in it, we
need to convert that to UTF-8 in Preprocessor::LookUpIdentifierInfo.

Of course, valid code that does *not* use UCNs will see only a very minimal
performance hit (checks after each identifier for non-ASCII characters,
checks when converting raw_identifiers to identifiers that they do not
contain UCNs, and checks when getting the spelling of an identifier that it
does not contain a UCN).

This patch also adds basic support for actual UTF-8 in the source. This is
treated almost exactly the same as UCNs except that we consider stray
Unicode characters to be mistakes and offer a fixit to remove them.

llvm-svn: 173369

Don't check lines beginning with '#', since they could contain a path with the unexpected word in them.

llvm-svn: 173307

llvm-svn: 172732

This is inspired by a number of false positives in real code, including
PR14968. I've added test cases reduced from these false positives to
test/Sema/unused-expr.c, as well as corresponding test cases that pass the
offending expressions as arguments to a no-op macro to ensure that we do warn
there.

This also removes my previous tweak from r166522/r166534, so that we warn on
unused cast expressions in macro arguments.

There were several test cases that were using -Wunused-value to test general
diagnostic emission features; I changed those to use other warnings or warn on
a macro argument expression. I stared at the test case for PR14399 for a while
with Richard Smith and we believe the new test case exercises the same
codepaths as before.

llvm-svn: 172696

No longer crashing with an assert when __has_include or __has_include_next is used outside of a preprocessor directive.  This fixes PR14837.

llvm-svn: 172639

there are macro expansions inside macro arguments where the arguments are
not expanded in the same order as listed; don't assert that all macro expansions
are in source order.

rdar://12397063

llvm-svn: 172018

Make sure clang puts tokens from different files on separate lines in "-E -P" mode.  <rdar://problem/12774044>
 

llvm-svn: 171944

llvm-svn: 171939

llvm-svn: 171372

make sure they came from the same kind of FileIDs.

Thanks to Abramo Bagnara for providing the test case.

llvm-svn: 170616

a note about where the macro is defined.

llvm-svn: 170228

Don't warn about disabled macro expansion if we see the name of a function-like macro which isn't immediately followed by '('. FreeBSD's stdio.h #defines foo(x) to (foo)(x), apparently.

llvm-svn: 169960

llvm-svn: 169458

__has_attribute, __has_extension, making them behave more akin to
conventional macros.

llvm-svn: 168268

llvm-svn: 168267

common LexStringLiteral function.  In doing so, some consistency problems have
been ironed out (e.g. where the first token in the string literal was lexed
with macro expansion, but subsequent ones were not) and also an erroneous
diagnostic has been corrected.

LexStringLiteral is complemented by a FinishLexStringLiteral function which
can be used in the situation where the first token of the string literal has
already been lexed.

llvm-svn: 168266

llvm-svn: 168265