GEP expressions were folded differently from before, change the tests to
reflect this.

llvm-svn: 194243

llvm-svn: 194242

Before:
  [self // break
      a:a
     aa:aa
  aaaaa:aaa];

After:
  [self // break
          a:a
         aa:aa
      aaaaa:aaa];

llvm-svn: 194241

llvm-svn: 194240

Under ARC++, a reference to a const Objective-C pointer is implicitly
treated as __unsafe_unretained, and can be initialized with (e.g.) a
__strong lvalue. Make sure this behavior does not break template
argument deduction and (related) that partial ordering still prefers a
'T* const&' template over a 'T const&' template when this case kicks
in. Fixes <rdar://problem/14467941>.

llvm-svn: 194239

last patch.

llvm-svn: 194238

llvm-svn: 194237

This syntactic checker looks for expressions on both sides of comparison
operators that are structurally the same. As a special case, the
floating-point idiom "x != x" for "isnan(x)" is left alone.

Currently this only checks comparison operators, but in the future we could
extend this to include logical operators or chained if-conditionals.

Checker by Per Viberg!

llvm-svn: 194236

An Objective-C for-in loop will have zero iterations if the collection is
empty. Previously, we could only detect this case if the program asked for
the collection's -count /before/ the for-in loop. Now, the analyzer
distinguishes for-in loops that had zero iterations from those with at
least one, and can use this information to constrain the result of calling
-count after the loop.

In order to make this actually useful, teach the checker that methods on
NSArray, NSDictionary, and the other immutable collection classes don't
change the count.

<rdar://problem/14992886>

llvm-svn: 194235

The path note that says "Loop body executed 0 times" has been changed to
"Loop body skipped when range is empty" for C++11 for-range loops, and to
"Loop body skipped when collection is empty" for Objective-C for-in loops.

Part of <rdar://problem/14992886>

llvm-svn: 194234

NS_RETURNS_INNER_POINTER ends up unintentionally 
on the @property under -objcmt-migrate-all 
// rdar://15396636

llvm-svn: 194233

Produces neater IR in significantly less time.

(~18% faster -O0 compile time for sqlite3 with -fsanitize=undefined)

llvm-svn: 194231

llvm-svn: 194229

llvm-svn: 194228

llvm-svn: 194226

The preprocessor currently recognizes module declarations to load a
module based on seeing the 'import' keyword followed by an
identifier. This sequence is fairly unlikely in C (one would need a
type named 'import'), but is more common in Objective-C (where a
variable named 'import' can cause problems). Since import declarations
currently require a leading '@', recognize that in the preprocessor as
well. Fixes <rdar://problem/15084587>.

llvm-svn: 194225

When performing an Objective-C message send to a value of class type,
perform a contextual conversion to an Objective-C pointer type. We've
had this for a long time, but it recently regressed. Fixes
<rdar://problem/15234703>.

llvm-svn: 194224

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

llvm-svn: 194223

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

llvm-svn: 194222

to avoid breaking AST invariants by reusing Stmt nodes within the same
function.

llvm-svn: 194217

Before:
  #define M(NAME) assert(!Context.Verifying &&#NAME);

After:
  #define M(NAME) assert(!Context.Verifying && #NAME);

This fixes llvm.org/PR16156.

llvm-svn: 194216

llvm-svn: 194215

Before:
  [self aaaaaaaaaaaaaaa:aaaaaaaaaaaaaaa | aaaaaaaaaaaaaaa | aaaaaaaaaaaaaaa |
                           aaaaaaaaaaaaaaa | aaaaaaaaaaaaaaa | aaaaaaaaaaaaaaa |
                           aaaaaaaaaaaaaaa | aaaaaaaaaaaaaaa];
  [self aaaaaaaaaaaaaaa:aaaaaaaaaaaaaaa,
      aaaaaaaaaaaaaaa, aaaaaaaaaaaaaaa, aaaaaaaaaaaaaaa, aaaaaaaaaaaaaaa,
      aaaaaaaaaaaaaaa, aaaaaaaaaaaaaaa, aaaaaaaaaaaaaaa];

After:
  [self aaaaaaaaaaaaaaa:aaaaaaaaaaaaaaa | aaaaaaaaaaaaaaa | aaaaaaaaaaaaaaa |
                        aaaaaaaaaaaaaaa | aaaaaaaaaaaaaaa | aaaaaaaaaaaaaaa |
                        aaaaaaaaaaaaaaa | aaaaaaaaaaaaaaa];
  [self aaaaaaaaaaaaaaa:aaaaaaaaaaaaaaa, aaaaaaaaaaaaaaa, aaaaaaaaaaaaaaa,
                        aaaaaaaaaaaaaaa, aaaaaaaaaaaaaaa, aaaaaaaaaaaaaaa,
                        aaaaaaaaaaaaaaa, aaaaaaaaaaaaaaa];

This addresses llvm.org/PR15349 and llvm.org/PR16185.

llvm-svn: 194214

forget to clean up temporaries at the end of it.

llvm-svn: 194213

llvm-svn: 194212

llvm-svn: 194211

Before:
  Constructor()
      : aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa(aaaaaaaaaaaaaaaaaaaaaaaaa(aaaa,
                                                                      aaaa)) {}
After:
  Constructor()
      : aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa(
            aaaaaaaaaaaaaaaaaaaaaaaaa(aaaa, aaaa)) {}

llvm-svn: 194210

As a side-effect, constructors definitions will correctly be recognized
and formatted as function declarations. Tests will be added in a
follow-up patch actually using the correct recognition.

llvm-svn: 194209

Also - others have complained about some white space issues - sorry about that - continues to be a pain point for me - will try and see what I can do with clang-format this evening after work - as a short term fix, if anyone can email me the files that they have already identified with issues, it would help me speed up a focused fix. sorry.

llvm-svn: 194206

Before:
  Constructor::Constructor()
      : some_value{ //
            aaaaaaa //
  } {}

After:
  Constructor::Constructor()
      : some_value{ //
            aaaaaaa //
        } {}

llvm-svn: 194204

Minor refinement of VTableBuilder.h: fix wrong indentation, rename a struct field with a more appropriate name

llvm-svn: 194202

llvm-svn: 194200

Ubuntu has published its Saucy release. 'Trusty Tahr' dev has just started. Add its support in Clang

llvm-svn: 194198

llvm-svn: 194197

llvm-svn: 194194

llvm-svn: 194192

This hasn't been used for some time.

llvm-svn: 194191

llvm-svn: 194190

llvm-svn: 194189

Both Richard and I felt that the current wording in the working paper needed some tweaking - Please see http://llvm-reviews.chandlerc.com/D2035 for additional context and references to core-reflector messages that discuss wording tweaks.

What is implemented is what we had intended to specify in Bristol; but, recently felt that the specification might benefit from some tweaking and fleshing.  

As a rough attempt to explain the semantics: If a nested lambda with a default-capture names a variable within its body, and if the enclosing full expression that contains the name of that variable is instantiation-dependent - then an enclosing lambda that is capture-ready (i.e. within a non-dependent context) must capture that variable, if all intervening nested lambdas can potentially capture that variable if they need to, and all intervening parent lambdas of the capture-ready lambda can and do capture the variable.      

Of note, 'this' capturing is also currently underspecified in the working paper for generic lambdas.  What is implemented here is if the set of candidate functions in a nested generic lambda includes both static and non-static member functions (regardless of viability checking - i.e. num and type of parameters/arguments) - and if all intervening nested-inner lambdas between the capture-ready lambda and the function-call containing nested lambda can capture 'this' and if all enclosing lambdas of the capture-ready lambda can capture 'this', then 'this' is speculatively captured by that capture-ready lambda.

Hopefully a paper for the C++ committee (that Richard and I had started some preliminary work on) is forthcoming. 

This essentially makes generic lambdas feature complete, except for known bugs. The more prominent ones (and the ones I am currently aware of) being:
  - generic lambdas and init-captures are broken - but a patch that fixes this is already in the works ...
  - nested variadic expansions such as:
    auto K = [](auto ... OuterArgs) {
      vp([=](auto ... Is) {
          decltype(OuterArgs) OA = OuterArgs;
          return 0;
        }(5)...);
      return 0;
    };
    auto M = K('a', ' ', 1, " -- ", 3.14); 
   currently cause crashes.  I think I know how to fix this (since I had done so in my initial implementation) - but it will probably take some work and back & forth with Doug and Richard.

A warm thanks to all who provided feedback - and especially to Doug Gregor and Richard Smith for their pivotal guidance: their insight and prestidigitation in such matters is boundless!

Now let's hope this commit doesn't upset the buildbot gods ;)

Thanks!

llvm-svn: 194188