Fixing the MSVC compiler warning a different way; removed use of static_cast and instead used a signed integer parameter.

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

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

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

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

MSVC accepts this:

class A {
  A::A();
};

Clang accepts regular member functions with extra qualification as an MS
extension, but not constructors.  This changes the parser to defer rejecting
qualified constructors so that the same Sema logic can apply to constructors as
regular member functions.  This also improves the error message when MS
extensions are disabled (in my opinion). Before it was:

/Users/jason/Desktop/test.cpp:2:8: error: expected member name or ';' after declaration specifiers
  A::A();
  ~~~~ ^
1 error generated.

After:

/Users/jason/Desktop/test.cpp:2:6: error: extra qualification on member 'A'
  A::A();
  ~~~^
1 error generated.

Patch by Jason Haslam.


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

Before (if only the second line was reformatted):
void f() {}
          void g() {}

After:
void f() {}
void g() {}

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

This redoes how '*' and '&' are classified as pointer / reference markers when
followed by ')', '>', or ','.

Previously, determineStarAmpUsage() marked a single '*' and '&' followed by
')', '>', or ',' as pointer or reference marker. Now, all '*'s and '&'s
preceding ')', '>', or ',' are marked as pointer / reference markers. Fixes
PR14884.

Since only the last '*' in 'int ***' was marked as pointer before (the rest
were unary operators, which don't reach spaceRequiredBetween()),
spaceRequiredBetween() now had to be thought about handing multiple '*'s in
sequence.

Before:
  return sizeof(int * *);
  Type **A = static_cast<Type * *>(P);

Now:
  return sizeof(int**);
  Type **A = static_cast<Type **>(P);

While here, also make all methods of AnnotatingParser except parseLine()
private.

Review URL: http://llvm-reviews.chandlerc.com/D384



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

    
Adding overloads of allOf accepting 4 and 5 arguments.
    
Reviewer: klimek



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

Rename -constructors test to just -structors as in fact it tests dtors too. Also, fix a minor typo in the test.

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

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

MarkMemberReferenced instead of marking functions referenced directly. An audit
of callers to MarkFunctionReferenced and DiagnoseUseOfDecl also caused a few
other changes:
 * don't mark functions odr-used when considering them for an initialization
   sequence. Do mark them referenced though.
 * the function nominated by the cleanup attribute should be diagnosed.
 * operator new/delete should be diagnosed when building a 'new' expression.


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

rdar://12046763

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

the linkage of functions and variables while merging declarations from modules,
and we don't necessarily have enough of the rest of the AST loaded at that
point to allow us to compute linkage, so serialize it instead.


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

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

+ added progress information for several checkers

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

calling std::terminate().  rdar://11904428

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

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

lexical storage but not visible storage' case in C++. It's unclear whether we
even need the special-case handling for C++, since it seems to be working
around our not serializing a lookup table for the TU in C. But in any case,
the assertion is incorrect.


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

expression.

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

Patch by Joey Gouly!

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

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

of immediately afterwards.

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

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

move-constructors and move-assignment operators, use memcpy to copy adjacent
POD members.

Previously, classes with one or more Non-POD members would fall back on
element-wise copies for all members, including POD members. This often
generated a lot of IR. Without padding metadata, it wasn't often possible
for the LLVM optimizers to turn the element-wise copies into a memcpy.

This code hasn't yet received any serious tuning. I didn't see any serious
regressions on a self-hosted clang build, or any of the nightly tests, but
I think it's important to get this out in the wild to get more testing.
Insights, feedback and comments welcome.

Many thanks to David Blaikie, Richard Smith, and especially John McCall for
their help and feedback on this work.



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

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

declarations if we didn't have a lookup map when the external decls were added.


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

of @throw statement by finding location of the ';'
correctly. // rdar://13186010


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

[Modules] Cope better with top-level declarations loaded after being declared in the current translation unit <rdar://problem/13189985>.

These two related tweaks to keep the information associated with a
given identifier correct when the identifier has been given some
top-level information (say, a top-level declaration) and more
information is then loaded from a module. The first ensures that an
identifier that was "interesting" before being loaded from an AST is
considered to be different from its on-disk counterpart. Otherwise, we
lose such changes when writing the current translation unit as a
module.

Second, teach the code that injects AST-loaded names into the
identifier chain for name lookup to keep the most recent declaration,
so that we don't end up confusing our declaration chains by having a
different declaration in there.


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

Before:
  for (id foo in[self getStuffFor : bla]) {
  }

Now:
  for (id foo in [self getStuffFor:bla]) {
  }

"in" is treated as loop keyword if the line starts with "for", and as a
regular identifier else. To check for "in", its IdentifierInfo is handed
through a few layers.



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

You can run tests with -debug instead now.

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

In google style, trailing comments are separated by two spaces. This
patch fixes the counting of these spaces and prevents clang-format from
creating a line with 81 columns.

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

Now correctly formats:
 #define A \
   \
   b;
to
 #define A b;

Added the state whether an unwrapped line is a macro to the debug
output.

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

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

Before:
operatorvoid*();
operator vector< A< A>>();

After:
operator void *();
operator vector<A<A> >();

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

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

The more general code for formatting ObjC method exprs does this and more,
it's no longer necessary to special-case this. No behavior change.



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

As it turns out, this already works reasonably well.

This example from http://clang.llvm.org/docs/ObjectiveCLiterals.html
NSDictionary *dictionary = @{
    @"name" : NSUserName(),
    @"date" : [NSDate date],
    @"processInfo" : [NSProcessInfo processInfo]
};

is formatted like
NSDictionary *dictionary = @{ @"name" : NSUserName(), @"date" : [NSDate date],
                              @"processInfo" : [NSProcessInfo processInfo] };

There's already a FIXME in NestedStaticInitializers about supporting one
initializer per line, which is really all that's missing here too.



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

(From http://clang.llvm.org/docs/ObjectiveCLiterals.html.)



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

Before:
  @{
  foo:
    bar
  }
  ;

Now:
  @{ foo : bar };

parseBracedList() already does the right thing from an UnwrappedLineParser
perspective, so check for "@{" in all loops that process constructs that can
contain expressions and call parseBracedList() if found.



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

Apple's kernel engineers have been expecting this behavior even though
we've never implemented it before, as far as I can tell. In recent months,
clang has gotten better at using vector instructions to optimize memcpy-like
operations, and that has exposed problems when vector/floating-point
instructions are used in kexts that don't support that. This behavior also
matches what Apple's GCC did for PowerPC targets.

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