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

llvm-svn: 194243

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

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

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

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

llvm-svn: 194217

llvm-svn: 194215

forget to clean up temporaries at the end of it.

llvm-svn: 194213

llvm-svn: 194212

llvm-svn: 194211

llvm-svn: 194197

llvm-svn: 194192

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

llvm-svn: 194168

llvm-svn: 194162

follow when building a class member access expression. Based on a patch by
Rahul Jain!

llvm-svn: 194161

On the microsoft ABI clang is producing one weak_odr and one linkonce_odr
destructor, which is reasonable since only one is required.

The fix is simply to move the assert past the special case treatment of
linkonce_odr.

llvm-svn: 194158

test case.

llvm-svn: 194157

llvm-svn: 194132

llvm-svn: 194124

llvm-svn: 194119

earlier 'non-constant' diagnostic with a later one if the earlier one was from
a side-effect we thought we could evaluate past.

llvm-svn: 194117

This patch adds the same behavior to clang.

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

llvm-svn: 194115

on smart pointers.  -Wthread-safety-beta only.

llvm-svn: 194103

NS_RETURNS_INNER_POINTER under -objcmt-returns-innerpointer-property
flag (off by default), as older compilers do not support such annotations.
// rdar://15396636

llvm-svn: 194100

bit more robust against future changes. This includes a slight diagnostic
improvement: if we know we're only trying to form a constant expression, take
the first diagnostic which shows the expression is not a constant expression,
rather than preferring the first one which makes the expression unfoldable.

llvm-svn: 194098

hack of passing -fconst-strings to -cc1, but at least the driver uses
the regular warning checking code path.

Since we don't support a warning that is DefaultIgnore in one language
but not in another, this patch creates a dummy C only warning in the same
group as the existing one to get the desired effect.

llvm-svn: 194097

This is a small optimization on linux, but should help more on windows
where msvc only outputs one destructor if there would be two identical ones.

llvm-svn: 194095

Revert this patch until cases of rejected valid code (e.g. identifiers
that require ADL to be resolved properly) are fixed.

llvm-svn: 194088

llvm-svn: 194086

llvm-svn: 194082

Third time's the charm, sorry for the noise.

llvm-svn: 194076

XFAIL wasn't enough for some of the build servers.

llvm-svn: 194073

Turns out this has always been crashing since the test landed in
r186647:

  Assertion failed: (Access != AS_none && "Access specifier is AS_none inside a record decl"), function CheckAccessDeclContext, file clang/lib/AST/DeclBase.cpp, line 690.

Needs attention.

llvm-svn: 194072

llc waits for input on stdin, which was not provided in this test. It
was running only thanks to a quirk in the way lit concatenates
commands.

llvm-svn: 194071