Assume none of the ObjC messages defined in system headers free memory,
except for the ones containing 'freeWhenDone' selector. Currently, just
assume that the region escapes to the messages with 'freeWhenDone'
(ideally, we want to treat it as 'free()').

For now, always assume that regions escape when passed to C++ methods.

llvm-svn: 151410

explicit conversion functions to initialize the argument to a
copy/move constructor that itself is the subject of direct
initialization. Since we don't have that much context in overload
resolution, we end up threading more flags :(.

Fixes <rdar://problem/10903741> / PR10456. 

llvm-svn: 151409

llvm-svn: 151407

llvm-svn: 151405

enumeration type with a fixed underlying type is complete. Fixes
<rdar://problem/10916155>.

llvm-svn: 151403

__keywords or none of them.

llvm-svn: 151401

llvm-svn: 151400

the declaration, not at the type of the DeclRefExpr, since within a lambda the
DeclRefExpr can be more const than the declaration is.

llvm-svn: 151399

against a large project.

llvm-svn: 151395

  A defaulted default constructor for a class X is defined as deleted if [...]
    -  X is a union and all of its variant members are of const-qualified type.

A pedantic reading therefore says that

 union X { };

has a deleted default constructor, which is both silly and almost
certainly unintended. Pretend as if this this read

    - X is a union with one or more variant members, and all of its
      variant members are of const-qualified type. 

llvm-svn: 151394

llvm-svn: 151389

llvm-svn: 151387

llvm-svn: 151386

"C++0x". Use "C++98" to refer to C++98, not "C++". Add heading for C++98
support section.

llvm-svn: 151381

agreed on IRC, any remaining issues are best dealt with as bugs.

We have no __has_feature check for this; please shout if you'd like one. This
feature seems too small to be worth its own release notes bullet (again, please
shout if you disagree).

llvm-svn: 151380

llvm-svn: 151378

llvm-svn: 151377

llvm-svn: 151376

  - Make sure that the block expression is instantiation-dependent if the
    block is in a dependent context
  - Make sure that the C++ 'this' expression gets captured even if we
  don't rebuild the AST node during template instantiation. This would
  also have manifested as a bug for lambdas.

Fixes <rdar://problem/10832617>.

llvm-svn: 151372

llvm-svn: 151371

This ensures that we report the bugs associated with symbols going
out of scope in the correct function context.

llvm-svn: 151369

visiting 'return;' statement!

This most likely caused us to skip a bunch of code when analyzing with
inlining.

llvm-svn: 151368

the default for clang for some time now and can handle compiler-rt.

llvm-svn: 151367

llvm-svn: 151359

uninitialized. While there, restyle this function! No functionality change.

llvm-svn: 151357

llvm-svn: 151356

hasTrivialMoveConstructor().

llvm-svn: 151354

llvm-svn: 151353

that provides the behavior of the C++11 library trait
std::is_trivially_constructible<T, Args...>, which can't be
implemented purely as a library.

Since __is_trivially_constructible can have zero or more arguments, I
needed to add Yet Another Type Trait Expression Class, this one
handling arbitrary arguments. The next step will be to migrate
UnaryTypeTrait and BinaryTypeTrait over to this new, more general
TypeTrait class.

Fixes the Clang side of <rdar://problem/10895483> / PR12038.

llvm-svn: 151352

Make PathDiagnosticBuilder sensitive to varying LocationContexts, thus fixing a bug in the inlining diagnostics where the wrong location could be used.

llvm-svn: 151349

llvm-svn: 151347

Reapply r151317, but when computing the PathDiagnostic profile and size keep into account the nested structure.  Also fix a problem with how
inlining impacted Plist diagnostics, and adjust some ranges in the Plist output due to richer information.

llvm-svn: 151346

llvm-svn: 151343

llvm-svn: 151338

make sure we don't mistake ParmVarDecls for top-level decls.

Fixes rdar://10920009.

llvm-svn: 151330

Rework PathDiagnostic creation so that call stacks are captured by a nested PathDiagnosticCallPiece.

llvm-svn: 151317

llvm-svn: 151316

llvm-svn: 151314

test case that only runs on debug builds.

llvm-svn: 151311

Handle "#pragma GCC visibility" in a few more places.  Switch over "#pragma pack" to use the same handling that gcc does.  Fixes <rdar://problem/10871094> and <rdar://problem/10893316>.

(Hopefully, common usage of these pragmas isn't irregular enough to break our current handling.  Doug has ideas for a more crazy approach if necessary.)

llvm-svn: 151307