ObjC methods.

llvm-svn: 161324

llvm-svn: 161319

'clang-cpp'.

For now, the test uses "REQUIRES: shell" to determine if the host system
supports "ln -s", which it uses to create a 'clang-cpp' symlink. This is a bit
hacky and should likely be directly supported by lit.cfg.

llvm-svn: 161317

we know whether the function is virtual. But check it as soon as we do know;
in some cases we don't need to wait for an instantiation.

llvm-svn: 161316

been defined.

llvm-svn: 161315

llvm-svn: 161310

llvm-svn: 161303

We can be in the situation where we did not track the symbol before
realloc was called on it.

llvm-svn: 161294

resulting in issuance of unused static variable
warning now. // rdar://10777111

llvm-svn: 161291

This should fix the failing test on the buildbot as well.

llvm-svn: 161290

While there is no such thing as a "null reference" in the C++ standard,
many implementations of references (including Clang's) do not actually
check that the location bound to them is non-null. Thus unlike a regular
null dereference, this will not cause a problem at runtime until the
reference is actually used. In order to catch these cases, we need to not
prune out paths on which the input pointer is null.

llvm-svn: 161288

llvm-svn: 161287

llvm-svn: 161286

Like base constructors, delegating constructors require no further
processing in the CFGInitializer node.

Also, add PrettyStackTraceLoc to the initializer and destructor logic
so we can get better stack traces in the future.

llvm-svn: 161283

Because of this, we would previously emit NO path notes when a parameter
is constrained to null (because there are no stores). Now we show where we
made the assumption, which is much more useful.

llvm-svn: 161280

llvm-svn: 161279

llvm-svn: 161278

llvm-svn: 161277

The visitor walks back through the ExplodedGraph as expected, but
it wasn't actually keeping track of when a value was assigned. This
meant that it only worked when the value was assigned when the variable
was defined.

Tests in the next commit (dependent on another change).

llvm-svn: 161276

This only applies in the case where ->* is not overloaded, since it
specifically looks for BinaryOperator and not CXXOperatorCallExpr.

llvm-svn: 161275

llvm-svn: 161274

llvm-svn: 161266

llvm-svn: 161265

In the following code, find the type of the symbolic receiver by
following it and updating the dynamic type info in the state when we
cast the symbol from id to MyClass *.

  MyClass *a = [[self alloc] init];
  return 5/[a testSelf];

llvm-svn: 161264

the function returns void.

llvm-svn: 161261

Fix crash if a literal operator template's template parameter pack is not a non-type template parameter pack. Patch by Andy Gibbs!

llvm-svn: 161260

llvm-svn: 161249

There is no reason why we should not track the memory which was not
allocated in the current function, but was freed there. This would
allow to catch more use-after-free and double free with no/limited IPA.

Also fix a realloc issue which surfaced as the result of this patch.

llvm-svn: 161248

llvm-svn: 161245

llvm-svn: 161244

llvm-svn: 161243

llvm-svn: 161237

By C++ standard, the vtable should be generated if the first non-inline
virtual function is defined in the TU.  Current version of clang doesn't
generate vtable if the first virtual function is defaulted, because the
key function is regarded as the defaulted function.

Patch by Li Kan!

llvm-svn: 161236

rdar://10112601

llvm-svn: 161227

switch.  Thanks Sean Silva for suggestion!

llvm-svn: 161225

engine.

The code that was supposed to split the tie in a deterministic way is
not deterministic. Most likely one of the profile methods uses a
pointer. After this change we do finally get the consistent diagnostic
output. Testing this requires running the analyzer on large code bases
and diffing the results.

llvm-svn: 161224

separate flags.

llvm-svn: 161217

rdar://12000401

llvm-svn: 161216

templates.

llvm-svn: 161215

There's still more work to be done here; this doesn't catch reference
parameters or return values. But it's a step in the right direction.

Part of <rdar://problem/11212286>.

llvm-svn: 161214