llvm-svn: 145984

(Previously, Clang used it's implementation of dominators.)

The patch is contributed by Guoping Long!

llvm-svn: 145858

llvm-svn: 145857

This is a fixup for r145832.

The extra clauses do not matter after we remove the dependency on canReasonAbout(InitVal) in r145832.

llvm-svn: 145856

class.

We are going into the direction of handling SymbolData and other SymExpr
uniformly, so it makes less sense to keep two different SVal classes.
For example, the checkers would have to take an extra step to reason
about each type separately.

The classes have the same members, we were just using the SVal kind
field for easy differentiation in 3 switch statements. The switch
statements look more ugly now, but we can make the code more readable in
other ways, for example, moving some code into separate functions.

llvm-svn: 145833

ExprEngine.

Teach SimpleConstraintManager::assumeSymRel() to propagate constraints
to symbolic expressions.

+ One extra warning (real bug) is now generated due to enhanced
assumeSymRel().

llvm-svn: 145832

ConstraintManager::canReasonAbout() from the ExprEngine.

ExprEngine should not care if the constraint solver can reason about
something or not. The solver should be able to handle all the SymExprs.

To do this, the solver should be able to keep track of not only the
SymbolData but of all SymExprs. This is why we change SymbolRef to be an
alias of SymExpr*. When encountering an expression it cannot simplify,
the solver should just add the constraints to it.

llvm-svn: 145831

llvm-svn: 145830

of relying on SymbolID.

This way any expression can be printed (not only SymbolData).

llvm-svn: 145829

requiring CFG.

Adding more ugly code; the evnvironment printing should be moved to
envirnment at some point.

llvm-svn: 145828

llvm-svn: 145827

We trigger an error if free is called after a possibly failed allocation. Do not trigger the error if we know that the buffer is not null.

llvm-svn: 145584

We are getting name of the called function or it's declaration in a few checkers. Refactor them to use the helper function in the CheckerContext. 

llvm-svn: 145576

When analyzing a C++ method (without a specific caller), assume 'this' is non-null.  Fixes <rdar://problem/10508787>.

llvm-svn: 145575

explicit template specializations (which represent actual functions somebody wrote).

Along the way, refactor some other code which similarly cares about whether or
not they are looking at a template instantiation.

llvm-svn: 145547

llvm-svn: 145506

llvm-svn: 145495

Relax RegionStore to allow loads from CodeTextRegions.  Apparently you can actually write code that does this.  This seems worthy of a checker, but the StoreManager should handle the memory abstraction without crashing.  Fixes PR 11450.

llvm-svn: 145424

llvm-svn: 145274

There is an open radar to implement better scanf checking as a Sema warning. However, a bit of redundancy is fine in this case.

llvm-svn: 144964

When the solver and SValBuilder cannot reason about symbolic expressions (ex: (x+1)*y ), the analyzer conjures a new symbol with no ties to the past. This helps it to recover some path-sensitivity. However, this breaks the taint propagation.

With this commit, we are going to construct the expression even if we cannot reason about it later on if an operand is tainted.

Also added some comments and asserts.

llvm-svn: 144932

llvm-svn: 144928

Naming could be improved.. But we should first rename the classes in the SVal hierarchy.

llvm-svn: 144927

llvm-svn: 144871

llvm-svn: 144870

Manager. Added test to ensure proper binding of initialized values.
This patch fixes PR11249.

llvm-svn: 144831

llvm-svn: 144829

Change the ArrayBoundCheckerV2 to be more aggressive in reporting buffer overflows
when the offset is tainted. Previously, we did not report bugs when the state was
underconstrained (not enough information about the bound to determine if there is
an overflow) to avoid false positives. However, if we know that the buffer
offset is tainted - comes in from the user space and can be anything, we should
report it as a bug.

+ The very first example of us catching a taint related bug.
This is the only example we can currently handle. More to come...

llvm-svn: 144826

The checker is responsible for defining attack surface and adding taint to symbols.

llvm-svn: 144825

TaintTag.h will contain definitions of different taint kinds and their properties.
TaintManager will be responsible for implementing taint specific operations, storing taint.
ProgramState will provide API to add/remove taint.

llvm-svn: 144824

llvm-svn: 144823

many checkers are trying to get a name of the callee when visiting
a CallExpr, so provide a convenience API.

llvm-svn: 144820

[static analyzer] Tweak RetainCountChecker's diagnostics to correctly indicate if a message was due to a property access.  This can
potentially be refactored for other clients, and this is a regression from the refactoring of property acceses.

llvm-svn: 144571

[analyzer;Regionstore] handle loads from StringLiteral elements for StringLiterals representing wide strings.  Fixes PR 11294.

llvm-svn: 144563

[static analyzer] be more specific when running removeDeadBindings.  Instead of seeing if the predecessor node was a non-StmtPoint, check if it is specifically a BlockEntrance node.

llvm-svn: 144340

[static analyzer]: only call RemoveDeadBindings() when analyzing non-Expr stmts, entering a basic block, or analyzing non-consumed expressions.  This sigificantly speeds up analysis time, and reduces analysis time down to 27% less than before we linearized the CFG.

llvm-svn: 144332

literal types, as well as derived-to-base casts for lvalues and
derived-to-virtual-base casts.

llvm-svn: 144265

Analysis by Ted:
"
    if (stateZero && !stateNotZero) {

is checking to see if:

  (A)  "it is possible for the value to be zero"   (stateZero)

    AND

  (B) "it is not possible for the value to be non-zero"  (!stateNotZero)

That said, the only way for both B to be true AND A to be false is if the path is completely infeasible by the time we reach the divide-by-zero check.  For the most part (all cases?), such cases should automatically get pruned out at branches (i.e., an infeasible path gets dropped), which is the case in our tests.  So the question is whether or not such an infeasible path might not get dropped earlier?  I can't envision any right now.

Indeed, the rest of the checker assumes that if the bug condition didn't fire then 'stateNotZero' is non-NULL:

    C.addTransition(stateNotZero);
"

llvm-svn: 144114

llvm-svn: 143910

property references to use a new PseudoObjectExpr
expression which pairs a syntactic form of the expression
with a set of semantic expressions implementing it.
This should significantly reduce the complexity required
elsewhere in the compiler to deal with these kinds of
expressions (e.g. IR generation's special l-value kind,
the static analyzer's Message abstraction), at the lower
cost of specifically dealing with the odd AST structure
of these expressions.  It should also greatly simplify
efforts to implement similar language features in the
future, most notably Managed C++'s properties and indexed
properties.

Most of the effort here is in dealing with the various
clients of the AST.  I've gone ahead and simplified the
ObjC rewriter's use of properties;  other clients, like
IR-gen and the static analyzer, have all the old
complexity *and* all the new complexity, at least
temporarily.  Many thanks to Ted for writing and advising
on the necessary changes to the static analyzer.

I've xfailed a small diagnostics regression in the static
analyzer at Ted's request.

llvm-svn: 143867