Add a severe penalty for not using column layout for braced lists. If
there are solutions with column layout, these are generally preferable
over bin-packed solutions.

Before:
  std::vector<MyValues> aaaaaaaaaaaaaaaaaaa{ aaaaaaa, aaaaaaaaaa, aaaaa,
                                             aaaaaaaaaaaaaaa, aaa, aaaaaaaaaa, a,
                                             aaaaaaaaaaaaaaaaaaaaa, aaaaaaaaaaaa,
                                             aaaaaaaaaaaaaaaaaaa +
                                                 aaaaaaaaaaaaaaaaaaa,
                                             aaaaaaa, a };
After:
  std::vector<MyValues> aaaaaaaaaaaaaaaaaaa{
    aaaaaaa,      aaaaaaaaaa,
    aaaaa,        aaaaaaaaaaaaaaa,
    aaa,          aaaaaaaaaa,
    a,            aaaaaaaaaaaaaaaaaaaaa,
    aaaaaaaaaaaa, aaaaaaaaaaaaaaaaaaa + aaaaaaaaaaaaaaaaaaa,
    aaaaaaa,      a
  };

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

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

module. Use the marker to diagnose cases where we try to transition between
submodules when not at the top level (most likely because a closing brace was
missing at the end of a header file, but is also possible if submodule headers
attempt to do something fundamentally non-modular, like our .def files).


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

This will allow the completer to order results by relevance.

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

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

The new names will be more appropriate when the objects are taught to return
type information for the code completer.

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

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

The looked-up matchers will be used during code completion.

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

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

This is still an experimental attribute, but I wanted it in tree
for review.  It may still get yanked.

This attribute can only be applied to a class @interface, not
a class extension or category.  It does not change the type
system rules for Objective-C, but rather the implementation checking
for Objective-C classes that explicitly conform to a protocol.
During protocol conformance checking, clang recursively searches
up the class hierarchy for the set of methods that compose
a protocol.  This attribute will cause the compiler to not consider
the methods contributed by a super class, its categories, and those
from its ancestor classes.  Thus this attribute is used to force
subclasses to redeclare (and hopefully re-implement) methods if
they decide to explicitly conform to a protocol where some of those
methods may be provided by a super class.

This attribute intentionally leaves out properties, which are associated
with state.  This attribute only considers methods (at least right now)
that are non-property accessors.  These represent methods that "do something"
as dictated by the protocol.  This may be further refined, and this
should be considered a WIP until documentation gets written or this
gets removed.

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

This enables a micro-optimization in protocol conformance checking
to not examine the class hierarchy twice per method.

As part of this change, remove the default arguments from lookupInstanceMethod()
and lookupClassMethod().  It was becoming very redundant.  For clients
needing the default arguments, have them use the full API instead of
these convenience methods.

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

It apparently causes some versions of GCC to segfault.
http://bb.pgr.jp/builders/cmake-clang-x86_64-linux/builds/17175/steps/build_clang/logs/stdio

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

Patch by Kim Gräsman!

Laszlo Nagy and me both ran into the same issue with SpecIterator from DeclTemplate.h causing an error:

tools/clang/include/clang/AST/DeclTemplate.h:560:22: error:
      no matching constructor for initialization of 'SetIteratorType' (aka
      'FoldingSetVectorIterator<clang::FunctionTemplateSpecializationInfo,
      typename SmallVector<FunctionTemplateSpecializationInfo *, 8>::iterator>')
    SpecIterator() : SetIter() {}

(see e.g. http://lists.cs.uiuc.edu/pipermail/cfe-dev/2013-November/033642.html)

The problem is the SpecIterator default constructor which needs a non-existent SetIter default constructor. SpecIterator's default constructor is evidently dead code as any call to it would fail with the above error.

This patch removes it.

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

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

attribute on method declaration and implementation
match. This makes no sense. Most annotations are
meant for declarations only and one is for implementation.
This has been constant source of regresions and hackery to
get around special cases. I am removing this check.
Such checks must be done on a case by case basis and
when it makes sense. For example, it makes sense
for availability/deprecated and I will file a radar
for that. // rdar://15531984


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

Summary:
Make the negative test more specific.
Otherwise it can accidentally match injected code.

Reviewers: aaron.ballman

CC: klimek, cfe-commits, revane

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

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

Updating Subjects definitions for attributes based on semantic handling. Removes Subjects for things we cannot currently check, adds Subjects for things we can, and rectifies most discrepancies. Since Subjects are not currently handled in tablegen, there are no functional changes with this patch.

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

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

available always-inline functions. This breaks libc++'s locale
implementation. Code generation for this case should be fixed, but this
is a stop gap fix for clang 3.4.


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

info version number.

Will error out when modules have different version numbers.


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

tranalation @protocol expression. // rdar://15517895


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

Summary: Add support for the 'unless' matcher in the dynamic layer.

Reviewers: klimek

CC: cfe-commits, revane, klimek

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

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

Patch by Oliver Stannard!


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

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

Not long ago I made the CodeGen of for loops simplify the condition at
-O0 in the same way we do for if and conditionals. Unfortunately this
ties how loops and simple conditions work together too tightly, which
makes features such as instrumentation based PGO awkward.

Ultimately, we should find a more general way to simplify the logic in
a given condition, but for now we'll just avoid using EmitBranchOnBool
for loops, like we already do for while and do loops.

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

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

Deleting three tests that are redundant with test/Preprocessor/arm-target-features.c and test/Driver/arm-cortex-cpus.c

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

can't accidentally be allocated the wrong way (missing prefix data for decls
from AST files, for instance) and simplifies the CreateDeserialized functions a
little. An extra DeclContext* parameter to the not-from-AST-file operator new
allows us to ensure that we don't accidentally call the wrong one when
deserializing (when we don't have a DeclContext), allows some extra checks, and
prepares for some planned modules-related changes to Decl allocation.

No functionality change intended.


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

Diags aren't usually in the first person, and 'windows' isn't the correct
product spelling to use in prose. Sidestep issues completely by making this
error message platform-neutral.

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

This matches other README.txt files in LLVM and makes things more obvious on
Windows where it's likely to be read. CRLFs are retained for the same reason.

Also fix Visual Studio product name.

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

ASTUnit instances are allocated infrequently so it's fine to keep this field
around in all build configurations.

Assigns null to silence -Wunused-private-field in Release.

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

Before:
  template <typename aaaaaaaaaaa, typename bbbbbbbbbbbbb, template <typename>
            class cccccccccccccccccccccc, typename ddddddddddddd>
  class C {};

After:
  template <typename aaaaaaaaaaa, typename bbbbbbbbbbbbb,
            template <typename> class cccccccccccccccccccccc,
            typename ddddddddddddd>
  class C {};

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

Before:
  int count = set<int> { f(), g(), h() }
      .size();

After:
  int count = set<int>{f(), g(), h()}.size();

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

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

It was there all the time, but I missed adding a RUN line for it.


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

and testing of objc_bridgmutable attribute per
Aaron Ballman's comments.
// rdar://15498044


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

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

Test commit for the user "kromanova" to verify commit access. I removed "UNSUPPORTED" comment because unsigned __int128 type is in fact supported.



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

whose semantic is currently identical to objc_bridge,
but their differences may manifest down the road with
further enhancements. // rdar://15498044


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

inferred as 'assign', not 'assign' and 'strong'.
// rdar://15509831


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

In OpenCL a vector of 3 elements, acts like a vector of four elements.
So for a vector of size 3 the '.hi' and '.odd' accessors, would access
the elements {2, 3} and {1, 3} respectively.
However, in EmitStoreThroughExtVectorComponentLValue we are still operating on
a vector of size 3, so we should only access {2} and {1}. We do this by checking
the last element to be accessed, and ignore it if it is out-of-bounds.

EmitLoadOfExtVectorElementLValue doesn't have a similar problem, because it does
a direct shufflevector with undef, so an out-of-bounds access just gives an undef
value.

Patch by Anastasia Stulova!




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

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

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

Summary:
Now based on token merging. Now they are not only prevented from being
split, but are actually formatted as comparison operators.

Reviewers: djasper, klimek

Reviewed By: klimek

CC: cfe-commits, klimek

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

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