llvm-svn: 162550

Fixes <rdar://problem/11005770>.

llvm-svn: 162545

isWritten() returns false, if shouldVisitImplicitCode() returns true.
Previously those CXXCtorInitializers were always skipped.

In order to make this change easier to test, this patch also extends the
test class template ExpectedLocationVisitor to support arbitrary numbers
of expected matches and disallowed matches.

llvm-svn: 162544

They are labeled as not being enabled-by-default, and how else
are users going to test them.

Fixes <rdar://problem/11654923>

llvm-svn: 162543

databases. Move JSONCompilationDatabase.h to its own files and
register it as plugin.

llvm-svn: 162541

ASTMatchers have the same name as the corresponding AST nodes
but are lower case. The only exceptions are the "CXX" prefixes
which are not copied over to the matcher names as the goal is to
actually remove these prefixes from the AST node names.

llvm-svn: 162536

no clang can be found relative to the location of scan-build.

Fixes <rdar://problem/11691794>

llvm-svn: 162535

When reallocation of a non-allocated (not owned) symbol fails do not
expect it to be freed.

llvm-svn: 162533

This code has been added a while ago and removing it does not trigger
any test failures. The false positives it was trying to suppress are
probably handled by other logic (ex: special handling of delegates).

llvm-svn: 162529

(I am not sure if we should move the setters and getters as well and
make them into static methods..)

llvm-svn: 162528

 * when checking that a pointer or reference refers to appropriate storage for a type, also check the alignment and perform a null check
 * check that references are bound to appropriate storage
 * check that 'this' has appropriate storage in member accesses and member function calls

llvm-svn: 162523

llvm-svn: 162521

llvm-svn: 162512

llvm-svn: 162511

generate the Input/Output expressions using Sema::ActOnIdExpression().

llvm-svn: 162509

With inlining, retain count checker starts tracking 'self' through the
init methods. The analyser results were too noisy if the developer
did not follow 'self = [super init]' pattern (which is common
especially in older code bases) - we reported self init anti-pattern AND
possible use-after-free. This patch teaches the retain count
checker to assume that [super init] does not fail when it's not consumed
by another expression. This silences the retain count warning that warns
about possibility of use-after-free when init fails, while preserving
all the other checking on 'self'.

llvm-svn: 162508

use \param and \returns in documentation.

Fixes PR13533.

llvm-svn: 162507

llvm-svn: 162506

This required changing all get() calls to data() and using the simpler constructors.

llvm-svn: 162501

This is how Xcode lets individual files be marked as non-ARC when the rest
of the project is ARC-enabled, so this is necessary for scan-build xcodebuild.

Patch by Paul Eipper!

llvm-svn: 162497

Until we have full support for pointers-to-members, we can at least
approximate some of their use by tracking null and non-null values.
We thus treat &A::m_ptr as a non-null void * symbol, and MemberPointer(0)
as a pointer-sized null constant.

This enables support for what is sometimes called the "safe bool" idiom,
demonstrated in the test case.

llvm-svn: 162495

This is trivial; the UserDefinedConversion always wraps a CXXMemberCallExpr
for the appropriate conversion function, so it's just a matter of
propagating that value to the CastExpr itself.

llvm-svn: 162494

llvm-svn: 162492

not be set for implicit instantiations, remove the FIXME.  This should be the
last bit for PR13634.  The actual fix happened in r162238.

Motivation: it might be misleading to mark implicit instantiations as
Decl::isImplicit = true.  Because then, in order to be consistent, we should
mark all instantiated members as implicit.  But the user did actually type the
declaration for the member, but the compiler played with it a little bit.

llvm-svn: 162488

by CodeGen.

In the long-term, much of the codegen logic will be shared between the GNU-style
and MS-style inline assembly, but for now I'm replicating this logic to avoid
regressions with the GNU-style.

llvm-svn: 162478

These were nops for quite a while and only lead to confusion. ASTMultiPtr
now behaves like a proper dumb array reference.

llvm-svn: 162475

lookup table as needing to be built.

This is required for LLDB, which provides the
contents of many DeclContexts through a custom
ExternalASTSource.

llvm-svn: 162471

"castAs<...>->doSomething()".  The analyzer was flagging these
as potential null dereferences, which is technically true.  The
invariants appear to be that these casts should never fail, so
let's use castAs<> instead and avoid a runtime check.

llvm-svn: 162468

statement starts with an identifier for which name lookup will fail either way,
look at later tokens to disambiguate in order to improve error recovery.

llvm-svn: 162464

ms-style inline asms.

llvm-svn: 162463

A CXXDefaultArgExpr wraps an Expr owned by a ParmVarDecl belonging to the
called function. In general, ExprEngine and Environment ought to treat this
like a ParenExpr or other transparent wrapper expression, with the inside
expression evaluated first.

However, if we call the same function twice, we'd produce a CFG that contains
the same wrapped expression twice, and we're not set up to handle that. I've
added a FIXME to the CFG builder to come back to that, but meanwhile we can
at least handle expressions that don't need to be explicitly evaluated:
literals. This probably handles many common uses of default parameters:
true/false, null, etc.

Part of PR13385 / <rdar://problem/12156507>

llvm-svn: 162453

llvm-svn: 162452

a gcc warning.

llvm-svn: 162444

llvm-svn: 162443

Patch by Niels Grewe!

llvm-svn: 162441

llvm-svn: 162440

llvm-svn: 162430

inconsistent ordering of results; instead, use use SmallPtrSet to
eliminate duplicates.

llvm-svn: 162429

on a null pointer. (This function happens to work for a null 'this' pointer, so
no test.)

llvm-svn: 162427

of a pointer for builtin emission, instead of just depending on the type of the
pointee.  <rdar://problem/11314941>.

llvm-svn: 162425