| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
llvm-svn: 165744
|
|
|
|
|
|
| |
objc_atomicCompareAndSwap.
llvm-svn: 165743
|
|
|
|
|
|
|
|
|
|
|
| |
Generating a sink is significantly different behavior from generating a
normal node, and a simple boolean parameter can be rather opaque. Per
offline discussion with Anna, adding new generation methods is the
clearest way to communicate intent.
No functionality change.
llvm-svn: 162215
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
when we generate a new ExplodedNode
we use the same Expr* as the one being currently visited. This is preparation for transitioning to having
ProgramPoints refer to CFGStmts.
This required a bit of trickery. We wish to keep the old Expr* bindings in the Environment intact,
as plenty of logic relies on it and there is no reason to change it, but we sometimes want the Stmt* for
the ProgramPoint to be different than the Expr* being used for bindings. This requires adding an extra
argument for some functions (e.g., evalLocation). This looks a bit strange for some clients, but
it will look a lot cleaner when were start using CFGStmt* in the appropriate places.
As some fallout, the diagnostics arrows are a bit difference, since some of the node locations have changed.
I have audited these, and they look reasonable.
llvm-svn: 154214
|
|
|
|
|
|
|
|
| |
At this point this is largely cosmetic, but it opens the door to replace
ProgramStateRef with a smart pointer that more eagerly acts in the role
of reclaiming unused ProgramState objects.
llvm-svn: 149081
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
entries map from
(Stmt*,LocationContext*) pairs to SVals instead of Stmt* to SVals.
This is needed to support basic IPA via inlining. Without this, we cannot tell
if a Stmt* binding is part of the current analysis scope (StackFrameContext) or
part of a parent context.
This change introduces an uglification of the use of getSVal(), and thus takes
two steps forward and one step back. There are also potential performance implications
of enlarging the Environment. Both can be addressed going forward by refactoring the
APIs and optimizing the internal representation of Environment. This patch
mainly introduces the functionality upon when we want to build upon (and clean up).
llvm-svn: 147688
|
|
|
|
|
|
|
|
| |
and name.
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
|
|
|
|
|
|
| |
Renamed PureNodeBuilder->StmtNodeBuilder.
llvm-svn: 142849
|
|
|
|
|
|
|
| |
- OSAtomicChecker
- ExprEngine::processStmt
llvm-svn: 142846
|
|
|
|
|
|
|
|
| |
essentially simulates inlining of compareAndSwap() by means of setting the NodeBuilder flags and calling ExprEngine directly.
This commit introduces a new callback just for this checker to unblock checker API cleanup.
llvm-svn: 141246
|
|
|
|
| |
llvm-svn: 137665
|
|
|
|
|
|
| |
and libStaticAnalyzer[*]. It was highly inconsistent, and very ugly to look at.
llvm-svn: 137537
|
|
|
|
|
|
|
| |
Having a notion of an actual ProgramPointTag will aid in introspection of the analyzer's behavior.
For example, the GraphViz output of the analyzer will pretty-print the tags in a useful manner.
llvm-svn: 137529
|
|
|
|
|
|
|
|
| |
separate TypedRegions that implement getValueType() from those that don't.
Patch by Olaf Krzikalla!
llvm-svn: 137498
|
|
|
|
|
|
|
|
| |
LLVM.h imports
them into the clang namespace.
llvm-svn: 135852
|
|
|
|
|
|
|
|
| |
direct lookup to values bound to expressions, without
resulting to lazy logic. This is critical for the OSAtomicChecker that does a simulated load on any arbitrary expression.
llvm-svn: 130292
|
|
|
|
| |
llvm-svn: 126726
|
|
|
|
| |
llvm-svn: 126610
|
|
|
|
|
|
|
|
| |
'include/clang/StaticAnalyzer/Core' and 'include/clang/StaticAnalyzer/Checkers'.
This layout matches lib/StaticAnalyzer, which corresponds to two StaticAnalyzer libraries.
llvm-svn: 125251
|
|
|
|
|
|
| |
lib/StaticAnalyzer/Checkers/InternalChecks.h
llvm-svn: 125121
|
|
layout. :)
Rename the 'EntoSA' directories to 'StaticAnalyzer'.
Internally we will still use the 'ento' namespace
for the analyzer engine (unless there are further
sabre rattlings...).
llvm-svn: 122514
|