If the output of 'ld -v' didn't match the regexes, CMake would previously error
with a message like:

  CMake Error at tools/clang/CMakeLists.txt:269 (string):
    string sub-command REGEX, mode REPLACE regex "[^0-9]*([0-9.]*).*" matched
    an empty string.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@223106 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@223105 91177308-0d34-0410-b5e6-96231b3b80d8

I'm explicitly setting LC_ALL=C somewhat for documentation, but
hopefully this also removes some host variation from the test results.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@223102 91177308-0d34-0410-b5e6-96231b3b80d8

environment variable is changed to strange things out from under it.
Prior to r223099 in LLVM, these test cases would crash in various ways
(assert fails, stack exhaustion, etc.).

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@223100 91177308-0d34-0410-b5e6-96231b3b80d8

I added this check a while back but then made a note to myself that it
should be completely unnecessary since iOS always uses PIC code-gen for
aarch64. Since I could never come up with any reason why it would be
necessary, I'm just going to remove it and we'll see if anything breaks.
rdar://problem/13627985

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@223097 91177308-0d34-0410-b5e6-96231b3b80d8

rather than trying to extract this information from the FileEntry after the
fact.

This has a number of beneficial effects. For instance, diagnostic messages for
failed module builds give a path relative to the "module root" rather than an
absolute file path, and the contents of the module includes file is no longer
dependent on what files the including TU happened to inspect prior to
triggering the module build.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@223095 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@223090 91177308-0d34-0410-b5e6-96231b3b80d8

Using lld on Windows requires calling link-lld.exe instead of
lld.exe.  This patch puts this knowledge into clang so that when
using the GCC style clang driver, it can properly delegate to
lld.

Differential Revision: http://reviews.llvm.org/D6428
Reviewed by: Reid Kleckner, Rui Ueyama

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@223086 91177308-0d34-0410-b5e6-96231b3b80d8

Richard rejected my Sema change to interpret an integer literal zero in
a varargs context as a null pointer, so -Wsentinel sees an integer
literal zero and fires off a warning. Only CodeGen currently knows that
it promotes integer literal zeroes in this context to pointer size on
Windows.  I didn't want to teach -Wsentinel about that compatibility
hack. Therefore, I'm migrating to C++11 nullptr.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@223079 91177308-0d34-0410-b5e6-96231b3b80d8

fallthrough happened to do the right thing in both cases.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@223064 91177308-0d34-0410-b5e6-96231b3b80d8

There was no test coverage for this before: Modifiying
EmitCXXOperatorMemberCallee() to not call CanDevirtualizeMemberFunctionCall()
didn't make any test fail.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@223056 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@223046 91177308-0d34-0410-b5e6-96231b3b80d8

Summary:
Speed up the variadic matchers by removing one indirect call.
Making the function pointer a template arguments allows the compiler to
inline the call instead of doing an runtime call by pointer.
Also, optimize the allOf() case to avoid redundant kind checks.
This speeds up our clang-tidy benchmark by ~2%

Reviewers: klimek

Subscribers: klimek, cfe-commits

Differential Revision: http://reviews.llvm.org/D6424

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@223029 91177308-0d34-0410-b5e6-96231b3b80d8

No functional changes, only code improvements.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@223010 91177308-0d34-0410-b5e6-96231b3b80d8

Revert r222993 while I investigate some MemorySanitizer failures.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@222995 91177308-0d34-0410-b5e6-96231b3b80d8

Now that TailRecursionElimination has been fixed with r222354, the
threshold on size for lifetime marker insertion can be removed. This
only affects named temporary though, as the patch for unnamed temporaries
is still in progress.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@222993 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@222969 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@222964 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@222963 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@222956 91177308-0d34-0410-b5e6-96231b3b80d8

We didn't consider types like ObjCSel as a substitution candidate.

This fixes PR21688.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@222941 91177308-0d34-0410-b5e6-96231b3b80d8

Add neon-vfpv3 to allow specifying both at the same time. This is not an
option that GCC supports, but follows the same track and should be
non-controversial.

Change-Id: Id9ec157c835937d7d11ad0f49dbe5171fac17658

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@222933 91177308-0d34-0410-b5e6-96231b3b80d8

This enables user to architecturally specify ARMv7A + VFPv4 + NEON.

Change-Id: I779b01fef5c47e5e4ac702ae24ed2f76a0e4c63f

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@222932 91177308-0d34-0410-b5e6-96231b3b80d8

According to OpenMP standard, Section 2.12.6, atomic Construct, '#pragma omp atomic write' is allowed to be used only for expression statements of form 'x = expr;', where x is a lvalue expression and expr is an expression with scalar type. Patch adds checks for it.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@222913 91177308-0d34-0410-b5e6-96231b3b80d8

This attribute serves as a hint to improve warnings about the ranges of
enumerators used as flag types. It currently has no working C++ implementation
due to different semantics for enums in C++. For more explanation, see the docs
and testcases.

Reviewed by Aaron Ballman.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@222906 91177308-0d34-0410-b5e6-96231b3b80d8

Now that LLVM can count the registers needed to implement AAPCS rules, we don't
need to duplicate that logic here. This means we can drop the explicit padding
and also use more natural types in many cases (e.g. "struct { float arr[3]; }"
used to end up as "[2 x double]" to avoid holes on the stack.

The one wrinkle is that AAPCS va_arg was also using the register counting
machinery. But the local replacement isn't too bad.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@222904 91177308-0d34-0410-b5e6-96231b3b80d8

Sphinx does not have a lexer for OpenCL, so falling back to C for the language on the code block. Also fixing an indentation warning. NFC to the content of the documentation itself.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@222894 91177308-0d34-0410-b5e6-96231b3b80d8

Before:
  var someVariable =
      function(x) { return x.zIsTooLongForOneLineWithTheDeclarationLine(); };

After:
  var someVariable = function(x) {
    return x.zIsTooLongForOneLineWithTheDeclarationLine();
  };

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@222893 91177308-0d34-0410-b5e6-96231b3b80d8

Before:
  var obj = {
    fooooooooo:
        function(x) { return x.zIsTooLongForOneLineWithTheDeclarationLine(); }
  };

After:
  var obj = {
    fooooooooo: function(x) {
      return x.zIsTooLongForOneLineWithTheDeclarationLine();
    }
  };

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@222892 91177308-0d34-0410-b5e6-96231b3b80d8

Before:
  someObject.new ();
  someObject.delete ();

After:
  someObject.new();
  someObject.delete();

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@222890 91177308-0d34-0410-b5e6-96231b3b80d8

Before:
  var MyLongClassName = goog.module.get('my.long.module.name.followedBy.MyLongClassName');

After:
  var MyLongClassName =
      goog.module.get('my.long.module.name.followedBy.MyLongClassName');

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@222888 91177308-0d34-0410-b5e6-96231b3b80d8

This fixes llvm.org/PR21676.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@222886 91177308-0d34-0410-b5e6-96231b3b80d8

consideration for C++17 for now. Update C++ status page to match.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@222865 91177308-0d34-0410-b5e6-96231b3b80d8

other function named "move".


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@222863 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@222853 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@222851 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@222848 91177308-0d34-0410-b5e6-96231b3b80d8

This fixes llvm.org/PR21677.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@222843 91177308-0d34-0410-b5e6-96231b3b80d8

For Java, don't do any of the deviations from Google Style that Chromium style
does for C++.

Chromium's Java follows Android Java style [1], which is roughly Google Java
style with an indent of 4 and a continuation indent of 8.

1: https://source.android.com/source/code-style.html



git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@222839 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@222837 91177308-0d34-0410-b5e6-96231b3b80d8