ElementRegion. I also removed 'ElementRegion::getArrayRegion',
although we may need to add this back.
This breaks a few test cases with RegionStore:
- 'array-struct.c' triggers an infinite recursion in RegionStoreManager. Need to investigate.
- misc-ps.m triggers a failure with RegionStoreManager as we now get the diagnostic:
'Line 159: Uninitialized or undefined return value returned to caller.'
There were a bunch of places that needed to be edit
RegionStoreManager, and we may not be passing all the correct 'element
types' down from GRExprEngine.
Zhongxing: When you get a chance, could you review this? I could have
easily screwed up something basic in RegionStoreManager.
llvm-svn: 70830
When the StoreManager doesn't reason well about pointer-arithmetic, propagate
the non-nullness constraint on a pointer value when performing pointer
arithmetic uisng ++/--.
llvm-svn: 69741
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
clients of the analyzer to designate custom assertion routines as "noreturn"
functions from the analyzer's perspective but not the compiler's.
llvm-svn: 68746
"The attached patch generates warnings of cases where an ObjC message is sent to
a nil object and the size of return type of that message is larger than the size
of void pointer. This may result in undefined return values as described in PR
2718. The patch also includes test cases."
llvm-svn: 68585
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
LHS type and the computation result type; this encodes information into
the AST which is otherwise non-obvious. Fix Sema to always come up with the
right answer for both of these types. Fix IRGen and the analyzer to
account for these changes. This fixes PR2601. The approach is inspired
by PR2601 comment 2.
Note that this changes real *= complex in CodeGen from a silent
miscompilation to an explicit error.
I'm not really sure that the analyzer changes are correct, or how to
test them... someone more familiar with the analyzer should check those
changes.
llvm-svn: 67889
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
- Conjure symbols at '--' and '++' unary operations
- Add utility method SVal::GetConjuredSymbolVal() and constify some arguments
along the way.
llvm-svn: 67395
conditions. Currently the analyzer does not reason well about
promotions/truncations of symbolic values, so at branch conditions when we see:
if (condition)
and condition is something like a 'short' or 'char', essentially ignore the
promotion to 'int' so that we track constraints on the original symbolic value.
We only ignore the casts if the underlying type has the same or fewer bits as
the converted type.
This fixes:
<rdar://problem/6619921>
llvm-svn: 66899
path-sensitivity, beyond checking to see if the value is "unknown" also check if
the ConstraintManager can handle the SVal. This allows us to recover some
path-sensitivity by actually discarding some information.
llvm-svn: 66627
Ted Kremenek