When running a make-based command, SATestBuild tries to append a -jN flag
with an appropriate N to run the build in parallel. However, it failed
to take into account that each line read includes a trailing newline
(unless it is the last line of a file without a trailing newline), which
resulted in the "-jN" appearing on a line on its own.

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

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

Add a test for the KFreeBSD define (#define __FreeBSD_kernel__ 1). This was introduced in commit r190048

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

so allow that case and add appropriate tests.

Patch by Ruiling Song!



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

Before:
  FirstToken->WhitespaceRange.getBegin()
      .getLocWithOffset(First->LastNewlineOffset);

After:
  FirstToken->WhitespaceRange.getBegin().getLocWithOffset(
      First->LastNewlineOffset);

Re-add logic to prevent breaking after an empty set of parentheses.
Basically it seems that calling a function without parameters is more
like navigating along the same object than it is a separate step of a
builder-type call.

We might need to extends this in future to allow "short" parameters that
e.g. are an index accessing a specific element.

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

Summary:
If a noreturn destructor is executed while returning a value from a function,
the resulting CFG has had two edges to the exit block. This crashed the analyzer,
because it expects that blocks with no terminators have only one outgoing edge.
I added code to avoid creating the second edge in this case.

PS: The crashes did not manifest themselves always, as usually the
NoReturnFunctionChecker would stop program evaluation before the analyzer hit
the assertion, but in the case of lifetime extended temporaries, the checker
failed to do that (which is a separate bug in itself).

Reviewers: jordan_rose

CC: cfe-commits

Differential Revision: http://llvm-reviews.chandlerc.com/D1513

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

Before:
  if (aaaaaaaaaaaaaaaaaaaaaaaaaa.aaaaaaaaaaaaaaaaaaaaaa(
          aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa) == 5) ...

After:
  if (aaaaaaaaaaaaaaaaaaaaaaaaaa.aaaaaaaaaaaaaaaaaaaaaa(
          aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa)
      == 5) ...

Also precompute startsBinaryExpression() to improve performance.

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

This fixes two issues:
1) The indent of a line comment was not adapted to the subsequent
   statement as it would be outside of a nested block.
2) A missing DryRun flag caused actualy breaks to be inserted in
   overly long comments while trying to come up with the best line
   breaking decisions.

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

PR17046, PR17092: Debug Info assert-on-valid due to member loss when context creation recreates the item the context is created for

By removing the possibility of strange partial definitions with no
members that older GCC's produced for the otherwise unreferenced outer
types of referenced inner types, we can simplify debug info generation
and correct this bug. Newer (4.8.1 and ToT) GCC's don't produce this
quirky debug info, and instead produce the full definition for the outer
type (except in the case where that type is dynamic and its vtable is
not emitted in this TU).

During the creation of the context for a type, we may revisit that type
(due to the need to visit template parameters, among other things) and
used to end up visiting it first there. Then when we would reach the
original code attempting to define that type, we would lose debug info
by overwriting its members.

By avoiding the possibility of latent "defined with no members" types,
we can be sure than whenever we already have a type in a cache (either a
definition or declaration), we can just return that. In the case of a
full definition, our work is done. In the case of a partial definition,
we must already be in the process of completing it. And in the case of a
declaration, the completed/vtable/etc callbacks can handle converting it
to a definition.

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

This expands very slightly what -Wtautological-compare considers to be
tautological to include implicit accesses to C++ fields and ObjC ivars.
I don't want to turn this into a full expression-identity check, but
these additions seem pretty well-contained, and maintain the theme
of checking for "x == x".

<rdar://problem/14431127>

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

Consumed Analysis: The 'consumable' attribute now takes a identifier specifying the default assumed state for objects of this class

This information is used for return states and pass-by-value parameter
states.

Patch by Chris Wailes.

Review by DeLesley Hutchins and Aaron Ballman.

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

initializer list containing a single element of type T, be sure to mark the
sequence as a list conversion sequence so that it is known to be worse than an
implicit conversion sequence that initializes a std::initializer_list object.


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

Without this patch, TreeTransform::TransformExpr uses a ridiculous amount of
stack space (around 5000 bytes).  Preventing inlining brings the stack usage
down to something sane.

On a testcase I have, on my computer, this allows changing -ftemplate-depth
from 210 to around 750 before we crash.  I'm not sure I should commit the
testcase, though: I don't want to cause test failures on platforms with less
stack space available.

<rdar://problem/14098189>.

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

constructor.


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

Consider something like the following:

struct X {
  virtual void foo(float x);
};
struct Y : X {
  void foo(double x) override;
};

The error is almost certainly that Y::foo() has the wrong signature,
rather than incorrect usage of the override keyword.  This patch
adds an appropriate diagnostic for that case.

Fixes <rdar://problem/14785106>.

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

Just a minor tweak to make it easier to track down the cause of fatal errors
with modules.

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

inferring NS_RETURNS_RETAINED, etc., return annotations.
Do not infer if these annotations are implicit
from the naming convention. Also add inference for
NS_CONSUMES_SELF annotation.


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

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

I don't have a reduced testcase yet.

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

DIBuilder now uses an identifier to reference DIType in base type field of
ptr_to_member (in r190081).


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

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

Summary: Closure classes for C++ lambdas are always compiler-generated.  This one-line change calls setImplicit(true) on them at creation time, such that a default RecursiveASTVisitor (or any for which shouldVisitImplicitCode returns false) will skip them.

Reviewers: rsmith, dblaikie

Reviewed By: dblaikie

CC: klimek, revane, cfe-commits, jordan_rose

Differential Revision: http://llvm-reviews.chandlerc.com/D1593

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

code to work for bit 32bit and 64bit APIs.
// rdar://14913632


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

We already use .obj as extension when the user provides a stem file
name (via /Fo), but were failing in the most basic case when the file
name is based on the input file.

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

builds.

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

Before:
 enum X : int { A, B, C };

After:
 enum X : int {
   A,
   B,
   C
 };

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

Summary:
Count column width instead of the number of code points. This also
includes correct handling of tabs inside string literals and comments (with an
exception of multiline string literals/comments, where tabs are present before
the first escaped newline).

Reviewers: djasper, klimek

Reviewed By: klimek

CC: cfe-commits, klimek

Differential Revision: http://llvm-reviews.chandlerc.com/D1601

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

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

As a result, Clang doesn't define the pre-processor macros that are expected
on this platform.

Thanks to Robert Millan for the patch



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

Before:
  constexpr char hello [] { "hello" };

After:
  constexpr char hello[]{ "hello" };

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

     getRealTypeByWidth and getIntTypeByWidth
  for ASTContext names are almost same(invokes new methods from TargetInfo):
     getIntTypeForBitwidth and getRealTypeForBitwidth.

As first commit for PR16752 fix: 'mode' attribute for unusual targets doesn't work properly
Description:
Troubles could be happened due to some assumptions in handleModeAttr function (see SemaDeclAttr.cpp).
For example, it assumes that 32 bit integer is 'int', while it could be 16 bit only.
Instead of asking target: 'which type do you want to use for int32_t ?' it just hardcodes general opinion. That doesn't looks pretty correct.
Please consider the next solution:
1. In Basic/TargetInfo add getIntTypeByWidth and getRealTypeByWidth virtual methods. By default current behaviour could be implemented here.
2. Fix handleModeAttr according to new methods in TargetInfo.
This approach is implemented in the patch attached to this post.

Fixes:
1st Commit (Current): Add new methods for TargetInfo:
     getRealTypeByWidth and getIntTypeByWidth
  for ASTContext names are almost same(invokes new methods from TargetInfo):
     getIntTypeForBitwidth and getRealTypeForBitwidth

2nd Commit (Next): Fix SemaDeclAttr, handleModeAttr function.



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

Mostly additional comments :-).

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

it works in the CL flavor driver.

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

Before:
  void f() {
    other(x.begin(), x.end(), //
                         [&](int, int) { return 1; });
  }

After:
  void f() {
    other(x.begin(), x.end(), //
          [&](int, int) { return 1; });
  }

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

Among other things, this enables (better) formatting lambdas and
constructs like:
  MACRO({
          long_statement();
          long_statement_2();
        },
        {
          long_statement();
          long_statement_2();
        },
        { short_statement(); }, "");

This fixes llvm.org/PR15381.

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

Summary:
I've had a test failure here while experimenting and I've found that it's
impossible to find what is wrong with the previous structure of the file. So I
have grouped the expected output with the function that produces it, to make
searching for discrepancies more obvious.

Reviewers: jordan_rose

CC: cfe-commits

Differential Revision: http://llvm-reviews.chandlerc.com/D1595

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

as this is going to be a common mistake (installing LLVM defaults to not putting
the tools onto the PATH).

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

is at the end of the line, point to the location after the double colon instead
of at the next token.  There is more context to be given this way.  In addition,
the next token can be several lines later.


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

This patch adds the following flags covering existing warnings:

-Wgnu-zero-variadic-macro-arguments
-Wgnu-imaginary-constant
-Wgnu-binary-literal
-Wgnu-zero-line-directive

Patch by Peter Lewis.

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

When an AST file is built based on another AST file, it can use a decl from
the fist file, and therefore mark the "isUsed" bit.  We need to note this in
the AST file so that the bit is set correctly when the second AST file is
loaded.

This patch introduces the distinction between setIsUsed() and markUsed() so
that we don't call into the ASTMutationListener callback when it wouldn't
be appropriate.

Fixes PR16635.

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