Skip to content
  1. Mar 09, 2012
    • Ted Kremenek's avatar
      [analyzer] Implement basic path diagnostic pruning based on "interesting" symbols and regions. · 1e809b4c
      Ted Kremenek authored
      Essentially, a bug centers around a story for various symbols and regions.  We should only include
      the path diagnostic events that relate to those symbols and regions.
      
      The pruning is done by associating a set of interesting symbols and regions with a BugReporter, which
      can be modified at BugReport creation or by BugReporterVisitors.
      
      This patch reduces the diagnostics emitted in several of our test cases.  I've vetted these as
      having desired behavior.  The only regression is a missing null check diagnostic for the return
      value of realloc() in test/Analysis/malloc-plist.c.  This will require some investigation to fix,
      and I have added a FIXME to the test case.
      
      llvm-svn: 152361
      1e809b4c
  2. Feb 05, 2012
  3. Jan 06, 2012
    • Ted Kremenek's avatar
      [analyzer] Make the entries in 'Environment' context-sensitive by making entries map from · 632e3b7e
      Ted Kremenek authored
      (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
      632e3b7e
  4. Aug 20, 2011
    • Anna Zaks's avatar
      Static Analyzer Diagnostics: Kill the addVisitorCreator(callbackTy, void*) API... · f86615ca
      Anna Zaks authored
      Static Analyzer Diagnostics: Kill the addVisitorCreator(callbackTy, void*) API in favor of addVisitor(BugReporterVisitor*).
      
      1) Create a header file to expose the predefined visitors. And move the parent(BugReporterVisitor) there as well.
      
      2) Remove the registerXXXVisitor functions - the Visitor constructors/getters can be used now to create the object. One exception is registerVarDeclsLastStore(), which registers more then one visitor, so make it static member of FindLastStoreBRVisitor.
      
      3) Modify all the checkers to use the new API.
      
      llvm-svn: 138126
      f86615ca
  5. Aug 18, 2011
    • Anna Zaks's avatar
      Remove EnhancedBugReport and RangedBugReport - pull all the extra... · 3a6bdf8f
      Anna Zaks authored
      Remove EnhancedBugReport and RangedBugReport - pull all the extra functionality they provided into their parent BugReport. The only functional changes are: made getRanges() non const - it adds default range to Ranges if none are supplied, made getStmt() private, which was another FIXME.
      
      llvm-svn: 137894
      3a6bdf8f
  6. Mar 01, 2011
  7. Feb 28, 2011
  8. Feb 10, 2011
  9. Feb 08, 2011
  10. Dec 23, 2010
  11. Dec 22, 2010
  12. Dec 20, 2010
  13. Mar 27, 2010
  14. Feb 08, 2010
  15. Jan 25, 2010
    • Ted Kremenek's avatar
    • Ted Kremenek's avatar
      Split libAnalysis into two libraries: libAnalysis and libChecker. · d6b87086
      Ted Kremenek authored
      (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
      d6b87086
  16. Nov 28, 2009
  17. Nov 23, 2009
    • Ted Kremenek's avatar
      Clean up the Checker API a little more, resolving some hidden bugs · f5735157
      Ted Kremenek authored
      along the way.  Important changes:
      
      1) To generate a sink node, use GenerateSink(); GenerateNode() is for
      generating regular transitions.  This makes the API clearer and also
      allows us to use the 'bool' option to GenerateNode() for a different
      purpose.
      
      2) GenerateNode() now automatically adds the generated node to the
      destination ExplodedNodeSet (autotransition) unless the client
      specifies otherwise with a bool flag.  Several checkers did not call
      'addTransition()' after calling 'GenerateNode()', causing the
      simulation path to be prematurely culled when a non-fail stop bug was
      encountered.
      
      3) Add variants of GenerateNode()/GenerateSink() that take neither a
      Stmt* or a GRState*; most callers of GenerateNode() just pass in the
      same Stmt* as provided when the CheckerContext object is created; we
      can just use that the majority of the time.  This cleanup also allows
      us to potentially coelesce the APIs for evaluating branches and
      end-of-paths (which currently directly use builders).
      
      4) addTransition() no longer needs to be called except for a few
      cases.  We now have a variant of addTransition() that takes a
      GRState*; this allows one to propagate the updated state without
      caring about generating a new node explicitly.  This nicely cleaned up
      a bunch of cases that called autoTransition() with a bunch of
      conditional logic surround the call (that common logic has now been
      swallowed up by addTransition() itself).
      
      llvm-svn: 89707
      f5735157
  18. Nov 14, 2009
  19. Nov 11, 2009
Loading