GRTransferFuncs had the conflated role of both constructing SVals (symbolic
expressions) as well as handling checker-specific logic. Now SValuator has the
role of constructing SVals from expressions and GRTransferFuncs just handles
checker-specific logic. The motivation is by separating these two concepts we
will be able to much more easily create richer constraint-generating logic
without coupling it to the main checker transfer function logic.

We now have one implementation of SValuator: SimpleSValuator.

SimpleSValuator is essentially the SVal-related logic that was in GRSimpleVals
(which is removed in this patch). This includes the logic for EvalBinOp,
EvalCast, etc. Because SValuator has a narrower role than the old
GRTransferFuncs, the interfaces are much simpler, and so is the implementation
of SimpleSValuator compared to GRSimpleVals. I also did a line-by-line review of
SVal-related logic in GRSimpleVals and cleaned it up while moving it over to
SimpleSValuator.

As a consequence of removing GRSimpleVals, there is no longer a
'-checker-simple' option. The '-checker-cfref' did everything that option did
but also ran the retain/release checker. Of course a user may not always wish to
run the retain/release checker, nor do we wish core analysis logic buried in the
checker-specific logic. The next step is to refactor the logic in CFRefCount.cpp
to separate out these pieces into the core analysis engine.

llvm-svn: 74229

llvm-svn: 74136

llvm-svn: 73954

No functionality change.

llvm-svn: 73952

Clean up code with ValueManager.

llvm-svn: 73951

array elements to 0 explicitly. Create 0 values with the element type.

llvm-svn: 73946

because the type of the symbol is used to create the default range. We need the
sign to be consistent.

llvm-svn: 73756

GRState->bindXXX and friends (and constify some arguments along the way).

llvm-svn: 73740

type. 

When retrieving the region value, if we are going to create a symbol value, use
the cast-to type if possible.

llvm-svn: 73690

array region, set its default value to conjured symbol. When retrieving its
element, create new region value symbol for the element.

Also fix some 80 columns violations.

llvm-svn: 71548

  SymbolRegionRValue => SymbolRegionValue
  SymExpr::RegionRValue => SymExpr::RegionValueKind

llvm-svn: 71322

TypedRegion::getValueType().

llvm-svn: 71321

 RValueType => ObjectType
 LValueType => LocationType

No functionality change.

llvm-svn: 71304

llvm-svn: 70865

no-outofbounds.c still fails. Previously it passed because the array index
is mistakenly a loc::ConcreteInt.

llvm-svn: 70844

layered regions.

llvm-svn: 69686

llvm-svn: 69577

get FunctionDecl with more general utility method.

llvm-svn: 69570

methods of SVal.

llvm-svn: 69565

ProgramPoints all the way through to GRCoreEngine.

NSString.m now fails with RegionStoreManager because of the void** cast.
Disabling use of region store for that test for now.

llvm-svn: 68845

llvm-svn: 68800

A CodeTextRegion wraps two kinds of data: FunctionDecl* or SymbolRef. 
The latter comes from the symbolic function pointer that are generated from
function calls or input data.

llvm-svn: 68777

llvm-svn: 68771

- Pull SVal::GetConjuredSymbol() and friends into ValueManager. This greatly
simplifies the calling interface to clients.

llvm-svn: 68731

llvm-svn: 68711

llvm-svn: 68703

type of the expression where we create the symbol.

llvm-svn: 68692

to eliminate the use of loc::SymbolVal.

llvm-svn: 68685

Enhance analyzer reasoning about sending messages to nil.  A nil receiver returns 0 for scalars of size <= sizeof(void*).

llvm-svn: 68629

when creating symbolic values, we distinguish between location and non-location
values. For location values, we create a symbolic region instead of a
loc::SymbolVal.

llvm-svn: 68373

llvm-svn: 68063

Zhongxing and I discussed by email.

Main changes:
- Removed SymIntConstraintVal and SymIntConstraint
- Added SymExpr as a parent class to SymbolData, SymSymExpr, SymIntExpr
- Added nonloc::SymExprVal to wrap SymExpr
- SymbolRef is now just a typedef of 'const SymbolData*'
- Bunch of minor code cleanups in how some methods were invoked (no functionality change)

This changes are part of a long-term plan to have full symbolic expression
trees. This will be useful for lazily evaluating complicated expressions.

llvm-svn: 67731

representing symbolic expressions like 'x'+3 and 'x'+'y'. The design is
subjected to change later when we fix the class hierarchy of symbolic
expressions.

llvm-svn: 67678

- Conjure symbols at '--' and '++' unary operations
- Add utility method SVal::GetConjuredSymbolVal() and constify some arguments
  along the way.

llvm-svn: 67395

SVal::GetRValueSymbolVal do the checking if we can symbolicate a type instead of
having BasicStoreManager do it (which wasn't always doing the check
consistently). Having this check in SVal::GetRValueSymbolVal keeps the check in
one centralized place.

llvm-svn: 67245

llvm-svn: 66555

SVal::getAsLocSymbol(). This simplifies the code and allows the retain/release
checker to (I believe) also correctly reason about location symbols wrapped in
SymbolicRegions.

Along the way I cleaned up SymbolRef a little, disallowing implicit casts to
'unsigned'.

llvm-svn: 65972

llvm-svn: 65956

- NonLoc::MakeVal() would use sizeof(unsigned) (literally) instead of consulting
  ASTContext for the size (in bits) of 'int'. While it worked, it was a
  conflation of concepts and using ASTContext.IntTy is 100% correct.
- RegionStore::getSizeInElements() no longer assumes that a VarRegion has the
  type "ConstantArray", and handles the case when uses use ordinary variables
  as if they were arrays.
- Fixed ElementRegion::getRValueType() to just return the rvalue type of its
  "array region" in the case the array didn't have ArrayType.
- All of this fixes <rdar://problem/6541136>

llvm-svn: 63347

their associated APIs.  We no longer need separate SymbolData objects
for fields, variables, etc.  Instead, we now associated symbols with
the "rvalue" of a MemRegion (i.e., the value stored at that region).
Now we only have two kinds of SymbolData objects: SymbolRegionRValue
and SymbolConjured.

This cleanup also makes the distinction between a SymbolicRegion and a
symbolic value that is a location much clearer.  A SymbolicRegion
represents a chunk of symbolic memory, while a symbolic location is
just a "pointer" with different possible values.  Without any specific
knowledge, a symbolic location resolves (i.e., via a dereference) to a
SymbolicRegion.  In the future, when we do better alias reasoning, a
symbolic location can become an alias for another location, thus
merging the constraints on the referred SymbolicRegion with the other
region.

llvm-svn: 62769