The ARM cycle-counter can be restricted by the operating system; it's
worth warning potential users of this issue.

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

Also fix a minor bug for constructor initializers with braced init lists.

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

Before: vector<int> v{ -1};
After:  vector<int> v{-1};

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

Put this somewhere on your path and use:

git clang-format

Awesome work by Mark Lodato. Many thanks!

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

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

Previously we would align:
f(); // comment
     // other comment
g();

Even if // other comment was at the start of the line. Now we do not
align trailing comments if they have been already aligned correctly
with the next line.

Thus,
f(); // comment
// other comment
g();
will not be changed, while:
f(); // comment
  // other commment
g();
will lead to the two trailing comments being aligned.

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

Replaces the use of WhitespaceStart + WhitspaceLength.
This made a bug in the formatter obvous where we would incorrectly
calculate the next column.

FIXME: There's a similar bug left regarding TokenLength. We should
probably also move to have a TokenRange instead.

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

Before:
vector<int> x { 1, 2, 3 };
After:
vector<int> x{ 1, 2, 3 };

Also add a style option to remove the spaces inside braced lists,
so that the above becomes:
std::vector<int> v{1, 2, 3};

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

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

Allows formatting of C++11 braced init list constructs, like:
vector<int> v { 1, 2, 3 };
f({ 1, 2 });

This involves some changes of how tokens are handled in the
UnwrappedLineFormatter. Note that we have a plan to evolve the
design of the token flow into one where we create all tokens
up-front and then annotate them in the various layers (as we
currently already have to create all tokens at once anyway, the
current abstraction does not help). Thus, this introduces
FIXMEs towards that goal.

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

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

specialization with modules enabled. Just don't merge them at all for now;
we'll revisit this when support for template merging is added.

In passing, make Decl::dump() a little safer to use with PCH/modules, by making
it not deserialize any additional declarations. From a debugger you can call
decls_begin() or similar first if you want to dump all child decls.


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

 * Treat _Atomic(T) as a literal type if T is a literal type.
 * Evaluate expressions of this type properly.
 * Fix a lurking bug where we built completely bogus ASTs for converting to
   _Atomic types in C++ in some cases, caught by the tests for this change.


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

Adding in parsing and the start of semantic support for __sptr and __uptr pointer type qualifiers.  This patch also fixes the correlated __ptr32 and __ptr64 pointer qualifiers so that they are truly type attributes instead of declaration attributes.

For more information about __sptr and __uptr, see MSDN: http://msdn.microsoft.com/en-us/library/aa983399.aspx

Patch reviewed by Richard Smith.


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

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

rdar://problem/13359718

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

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

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

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

Fixes <rdar://problem/13949982>

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

- The return type should be a pointer to the class type.
- Make the condition more specific.

rdar://problem/13359718

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

These are legitimate control-flow edges, but visually they add
no value.

Implements <rdar://problem/13941325>.

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

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

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

This is important if the user has multiple Xcodes installed on their
system -- we use xcodebuild to do a version check, and therefore we need
to make sure we match the actual build command.

Reported by Howard Ling!

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

Currently, blocks instantiated in templates lose their "signature as
written"; it's not clear if this is intentional. Change the analyzer's
use of BlockDecl::getSignatureAsWritten to check whether or not the
signature is actually there.

<rdar://problem/13954714>

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

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

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

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

Instead of selectively storing some changes and directly generating
replacements for others, we now notify the WhitespaceManager of the
whitespace before every token (and optionally with more changes inside
tokens).

Then, we run over all whitespace in the very end in original source
order, where we have all information available to correctly align
comments and escaped newlines.

The future direction is to pull more of the comment alignment
implementation that is now in the BreakableToken into the
WhitespaceManager.

This fixes a bug when aligning comments or escaped newlines in unwrapped
lines that are handled out of order:
  #define A \
    f({     \
      g();  \
    });
... now gets correctly layouted.

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

clang-format was a bit too aggressive when trying to keep labels and
values on the same line.

Before:
    llvm::outs()
         << "aaaaaaaaaaaaaaaaaaa: " << aaaaaaaaaaaaa(
                                           aaaaaaaaaaaaaaaaaaaaaaaaaaaa);
After:
  llvm::outs() << "aaaaaaaaaaaaaaaaaaa: "
               << aaaaaaaaaaaaa(aaaaaaaaaaaaaaaaaaaaaaaaaaaa);

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

This only affects styles that prevent bin packing. There, a break after
a template declaration also forced a line break after the function name.

Before:
template <class SomeType, class SomeOtherType>
SomeType
SomeFunction(SomeType Type, SomeOtherType OtherType) {}

After:
template <class SomeType, class SomeOtherType>
SomeType SomeFunction(SomeType Type, SomeOtherType OtherType) {}

This fixes llvm.org/PR16072.

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

Reduce the preference for breaking before a trailing 'const' according
to review comments on r182362.

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

If clang-format is confronted with long and deeply nested lines (e.g.
complex static initializers or function calls), it can currently try too
hard to find the optimal solution and never finish. The reason is that
the memoization does not work effectively for deeply nested lines.

This patch removes an earlier workaround and instead opts for
accepting a non-optimal solution in rare cases. However, it only does
so only in cases where it would have to analyze an excessive number of
states (currently set to 10000 - the most complex line in Format.cpp
requires ~800 states) so this should not change the behavior in a
relevant way.

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

The crash is triggered by the newly added option (-analyzer-config report-in-main-source-file=true) introduced in r182058.

Note, ideally, we’d like to report the issue within the main source file here as well.
For now, just do not crash.

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

operand of a unary address-of expression, not for *all* expressions!


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

function templates can use it as a return type.


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

*that* easy...

Try a bit harder to disambiguate. This is mostly straightforward, but for
=-style initializers, we actually need to know where an expression ends:

  [foo = bar baz]

is a message send, whereas

  [foo = bar + baz]

is a lambda-introducer. Handle this by parsing the expression eagerly, and
replacing it with an annotation token. By chance, we use the *exact same*
parsing rules in both cases (except that we need to assume we're inside a
message send for the parse, to turn off various forms of inapplicable
error recovery).


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

[analyzer;alternate edges] prune out extra edges to a subexpression where we dive-in and out of a subexpression.

Fixes <rdar://problem/13941891>.

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

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