llvm-svn: 146748

llvm-svn: 146683

is deterministic.

Non-determinism was the reason for the test which caused the earlier
buildbot failures, so re-enable the test.

llvm-svn: 146628

Some of the test cases do not currently work because the analyzer core
does not seem to call checkers for pre/post DeclRefExpr visits.
(Opened radar://10573500. To be fixed later on.)

llvm-svn: 146536

llvm-svn: 146535

llvm-svn: 146533

Also, allow adding taint to a region (not only a symbolic value).

llvm-svn: 146532

[analyzer] CStringChecker should not rely on the analyzer generating UndefOrUnknown value when it cannot reason about the expression.

We are now often generating expressions even if the solver is not known to be able to simplify it. This is another cleanup of the existing code, where the rest of the analyzer and checkers should not base their logic on knowing ahead of the time what the solver can reason about. 

In this case, CStringChecker is performing a check for overflow of 'left+right' operation. The overflow can be checked with either 'maxVal-left' or 'maxVal-right'. Previously, the decision was based on whether the expresion evaluated to undef or not. With this patch, we check if one of the arguments is a constant, in which case we know that 'maxVal-const' is easily simplified. (Another option is to use canReasonAbout() method of the solver here, however, it's currently is protected.)

This patch also contains 2 small bug fixes:
 - swap the order of operators inside SValBuilder::makeGenericVal.
 - handle a case when AddeVal is unknown in GenericTaintChecker::getPointedToSymbol.

llvm-svn: 146343

Forgot to commit the Header files. 
Rename generateUnknownVal -> makeGenericVal.

llvm-svn: 146337

Fix a bug in SimpleSValBuilder, where we should swap lhs and rhs when calling generateUnknownVal(), - the function which creates symbolic expressions when data is tainted. The issue is not visible when we only create the expressions for taint since all expressions are commutative from taint perspective.

Refactor SymExpr::symbol_iterator::expand() to use a switch instead of a chain of ifs.

llvm-svn: 146336

types are equivalent.

+ A taint test which tests bitwise operations and which was
triggering an assertion due to presence of the integer to integer cast.

llvm-svn: 146240

+ random comments

llvm-svn: 146199

llvm-svn: 146146

between the casted type of the return value of a malloc/calloc/realloc
call and the operand of any sizeof expressions contained within
its argument(s).

llvm-svn: 146144

llvm-svn: 146056

SVal can be not only a symbol, but a MemRegion. Add support for such
cases.

llvm-svn: 146006

for a foldable constant rather than an IR-level constant. This is still far too
liberal, but is a step in the right direction.

llvm-svn: 145990

llvm-svn: 145987

for finding dependent symbols for taint.

llvm-svn: 145986

 - Created a new SymExpr type - SymbolCast.
 - SymbolCast is created when we don't know how to simplify a NonLoc to
NonLoc casts.
 - A bit of code refactoring: introduced dispatchCast to have better
code reuse, remove a goto.
 - Updated the test case to showcase the new taint flow.

llvm-svn: 145985

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