Before:
  throw a *b;

Now:
  throw a * b;



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

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

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

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

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

This should make it slightly more readable as it more clearly separates
what happens where. No intended functional changes. More of this to
come..

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

Also set ObjC1 in the formatter tests.

The only effect of this flag in the lexer is that '@' now gets turned into
tok::at instead of tok::unknown.



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

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

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

All changes done by clang-format itself. No functional changes.

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

This addresses llvm.org/PR14830.

Before:
unsigned Cost =
    TTI.getMemoryOpCost(I->getOpcode(), VectorTy, SI->getAlignment(),
                        SI->getPointerAddressSpace());
CharSourceRange LineRange =
    CharSourceRange::getTokenRange(TheLine.Tokens.front().Tok.getLocation(),
                                   TheLine.Tokens.back().Tok.getLocation());

After:
unsigned Cost = TTI.getMemoryOpCost(I->getOpcode(), VectorTy,
                                    SI->getAlignment(),
                                    SI->getPointerAddressSpace());
CharSourceRange LineRange = CharSourceRange::getTokenRange(
                                TheLine.Tokens.front().Tok.getLocation(),
                                TheLine.Tokens.back().Tok.getLocation());

This required rudimentary changes to static initializer lists, but we
are not yet formatting them in a reasonable way. That will be done in a
subsequent patch.

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

In LLVM style, a single space should be enough. In Google style, two
spaces are required.

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

Before:
virtual void write(ELFWriter *writer, OwningPtr<FileOutputBuffer> &buffer) =
    0

After:
virtual void write(ELFWriter *writerrr,
                   OwningPtr<FileOutputBuffer> &buffer) = 0;

This addresses llvm.org/PR14815.

To implement this I introduced a line type during parsing and moved the
definition of TokenType out of the struct for increased readability.
Should have done the latter in a separate patch, but it would be hard to
pull apart now.

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

The case that we wanted to write a test for cannot happen, as the
UnwrappedLineParser already protects against it. Added an assert to
prevent regressions of that assumption.

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

First check only wrapped with i==8, second wrapped at i==2,8,18,28,...
This fix restores the intended behavior: i==8,18,28,...

Found with -fsanitize=integer.

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

while parsing #define's.

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

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

We would format:
  #define A \
    int f(a); int i;
as
  #define A \
    int f(a);\
    int i

The fix will break up macro definitions that could fit a line, but hit
the last column; fixing that is more involved, though, as it requires
looking at the following line.

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

Previously, we'd format
  int i;\
  // comment
as
  int i; // comment

The problem is that the escaped newline is part of the next token, and
thus the raw token text of the comment doesn't start with "//".

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

If a token follows directly on an escaped newline, the escaped newline
is stored with the token. Since we re-layout escaped newlines, we need
to treat them just like normal whitespace - thus, we need to increase
the whitespace-length of the token, while decreasing the token length
(otherwise the token length contains the length of the escaped newline
and we double-count it while indenting).

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

This fixes llvm.org/PR14823.

Before:
    local_state->SetString(prefs::kApplicationLocale, parent_local_state
                                ->GetString(prefs::kApplicationLocale));
After:
    local_state->SetString(
        prefs::kApplicationLocale,
        parent_local_state->GetString(prefs::kApplicationLocale));

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

Using added LLVM functionality in r171698. This works in GDB for member
variable pointers but not member function pointers. See the LLVM commit and
GDB bug 14998 for details.

Un-xfailing cases in the GDB 7.5 test suite will follow.

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

rather than doing it ourselves. This reflects the API changes in r171681.

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

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

these ideas don't get lost


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

If we find an unexpected closing brace, we must not stop parsing, as
we'd otherwise not layout anything beyond that point.

If we find a structural error on the highest level we'll not re-indent
anyway, but we'll still want to format within unwrapped lines.

Needed to introduce a differentiation between an expected and unexpected
closing brace.

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

This is coming up again and again on the mailing list and IRC.


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

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

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

To parse # correctly, we need to know whether it is the first token in a
line - we can deduct this either from the whitespace or seeing that the
token is the first in the file - we already calculate this information.
This patch moves the identification of the first token into the
getNextToken method and stores it inside the FormatToken, so the
UnwrappedLineParser can stay independent of the SourceManager.

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

Uses indent 0 for macros for now and resets the indent state to the
level prior to the preprocessor directive.

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

<objc/Protocol.h>. Caused by my recent changes for 
various builtin declarations of objc_msgSendSuper
variety. // rdar://12489098


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

Based on code review feedback for r171604 from Chandler Carruth &
Eric Christopher. Enabled by improvements to LLVM made in r171636.

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

A preprocessor directive cannot be started while we're parsing one.

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

Catch some cases I'd missed in r171605 related to unnamed parameters of record
type. This resolves all remaining cases of PR14573 suppression in the GDB 7.5
test suite. Fix to the test suite to follow.

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

A rather egregious example of the grep-style checking of old that I randomly
came across.

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

passes to a create-pass function instead of a direct constructor call.

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

Turns out that the ExecPath for the ObjC migrator would also get set.

Fixes <rdar://problem/12961769>.

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

LLVM ignores this data for now - patch for that to follow.

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

Referring back to the original commit (r115090) which was a frontend only test
I adjusted this test to verify the frontend change that was made, to emit the
protected access value in the flags metadata field.

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