Commit Graph

17 Commits

Author SHA1 Message Date
Ted Kremenek 70c090822d Correctly return early from BasicStoreManager::iterBindings() when the BindingsHandler returns false.
llvm-svn: 106182
2010-06-17 00:24:37 +00:00
Zhongxing Xu d4f1294f1e Remove extents of dead symbolic regions when RemoveDeadBindings.
This requires creating new persistent states due to the nature of GDM.

llvm-svn: 104668
2010-05-26 03:27:35 +00:00
Douglas Gregor 8385a06929 Introduce Type::isStructureOrClassType(), which does the obvious
thing. Audit all uses of Type::isStructure(), changing those calls to
isStructureOrClassType() as needed (which is alsmost
everywhere). Fixes the remaining failure in Boost.Utility/Swap.

llvm-svn: 102386
2010-04-26 21:31:17 +00:00
Zhongxing Xu 03fd76663e Mark CXXThisRegion in the current or parent stack frame context as live so that
their bindings are not removed.

llvm-svn: 98705
2010-03-17 03:35:08 +00:00
Ted Kremenek 7de5f32479 Enhance basic store to also lazily symbolicate VarRegions
with an 'unknown' memory space.

llvm-svn: 98110
2010-03-10 00:18:08 +00:00
Ted Kremenek 5d2bb1b9b3 [CFG]
After discussion with Zhongxing, don't force the initializer of DeclStmts to be
block-level expressions.

This led to some interesting fallout:

[UninitializedValues]

Always visit the initializer of DeclStmts (do not assume they are block-level expressions).

[BasicStore]

With initializers of DeclStmts no longer block-level expressions, this causes self-referencing initializers (e.g. 'int x = x') to no longer cause the initialized variable to be live before the DeclStmt.  While this is correct, it caused BasicStore::RemoveDeadBindings() to prune off the values of these variables from the initial store (where they are set to uninitialized).  The fix is to back-port some (and only some) of the lazy-binding logic from RegionStore to
BasicStore.  Now the default values of local variables are determined lazily as opposed
to explicitly initialized.

llvm-svn: 97591
2010-03-02 21:43:54 +00:00
Zhongxing Xu 6d3cc382df Since now we store the cast type with an ElementRegion, there is
no need to store a type with SymbolRegionValue.

llvm-svn: 97437
2010-03-01 06:56:52 +00:00
Zhongxing Xu c5f825eacd BindInternal is redundant. Remove it.
llvm-svn: 95540
2010-02-08 08:48:05 +00:00
Zhongxing Xu b02d4a0d11 Unify the implementation of getLValueElement of store managers.
It's more sophisticated than the original one of BasicStore. But it does
matter. 

llvm-svn: 95536
2010-02-08 08:17:02 +00:00
Zhongxing Xu f7f0cdc517 Unify the implementation of getLValueIvar and getLValueField of store managers.
llvm-svn: 95535
2010-02-08 07:58:06 +00:00
Zhongxing Xu 08515a5242 Move common methods to the base StoreManager class.
llvm-svn: 95534
2010-02-08 07:10:35 +00:00
Zhongxing Xu ad0ef84040 More GRState* -> Store changes.
llvm-svn: 95365
2010-02-05 05:34:29 +00:00
Zhongxing Xu f668204a6a More GRState* -> Store changes.
llvm-svn: 95362
2010-02-05 05:18:47 +00:00
Zhongxing Xu 7fcd8acbf8 More GRState* -> Store changes.
llvm-svn: 95360
2010-02-05 05:06:13 +00:00
Zhongxing Xu c7b9f950d7 More GRState* -> Store changes.
llvm-svn: 95357
2010-02-05 03:01:53 +00:00
Zhongxing Xu 4f8b9899bb Now that CastRetrievedVal returns SVal, there is no need to use CastResult.
llvm-svn: 95279
2010-02-04 02:39:47 +00:00
Ted Kremenek d6b8708643 Split libAnalysis into two libraries: libAnalysis and libChecker.
(1) libAnalysis is a generic analysis library that can be used by
    Sema.  It defines the CFG, basic dataflow analysis primitives, and
    inexpensive flow-sensitive analyses (e.g. LiveVariables).

(2) libChecker contains the guts of the static analyzer, incuding the
    path-sensitive analysis engine and domain-specific checks.

Now any clients that want to use the frontend to build their own tools
don't need to link in the entire static analyzer.

This change exposes various obvious cleanups that can be made to the
layout of files and headers in libChecker.  More changes pending.  :)

This change also exposed a layering violation between AnalysisContext
and MemRegion.  BlockInvocationContext shouldn't explicitly know about
BlockDataRegions.  For now I've removed the BlockDataRegion* from
BlockInvocationContext (removing context-sensitivity; although this
wasn't used yet).  We need to have a better way to extend
BlockInvocationContext (and any LocationContext) to add
context-sensitivty.

llvm-svn: 94406
2010-01-25 04:41:41 +00:00