[Static Analyzer] New checker hook: checkInitialState

2015-11-28 Thread Gabor Kozar via cfe-commits
Hi,

Once, long ago, I started working on this checker callback, but forgot
about it. I have decided to finish it now. Original discussion:
http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20131216/095565.html

The motivation was (pipermail doesn't seem to have my original mail, for
some reason):

> I had an issue recently with the Static Analyzer [while implementing a
> checker] that I wouldn't be able
 to detect when a function was entered - either through a call or
 serving as the entry point of the analysis. (I ended up using
 checkPreStmt and figuring out if we've been magically transported
 inside a function body and check the program state whether the
 necessary info was already recorded by checkPreCall. Not something I'd
 call nice by any means.)

The attached patch creates a new checker hook, with the signature:

> ProgramStateRef checkInitialState(const EntryPointInfo& EPInfo) /* non-
> const */;

EntryPointInfo is currently a very simple class containing a Decl* of
the declaration being used as an entry point and a ProgramStateRef of
the initial state.

Checkers implementing this hook can make changes to the program state by
returning a new one. They are also allowed to return nullptr, in which
case the analysis doesn't proceed further from that entry point.

Please let me know what you think!

---
Best regards,

Gábor 'ShdNx' Kozár http://gaborkozar.me

Index: include/clang/StaticAnalyzer/Core/Checker.h
===
--- include/clang/StaticAnalyzer/Core/Checker.h	(revision 254233)
+++ include/clang/StaticAnalyzer/Core/Checker.h	(working copy)
@@ -22,6 +22,7 @@
 namespace clang {
 namespace ento {
   class BugReporter;
+  class EntryPointInfo;
 
 namespace check {
 
@@ -426,6 +427,19 @@
   }
 };
 
+class InitialState {
+  template 
+  static ProgramStateRef _checkInitialState(void *checker, const EntryPointInfo &info) {
+return ((CHECKER *)checker)->checkInitialState(info);
+  }
+
+public:
+  template 
+  static void _register(CHECKER *checker, CheckerManager &mgr) {
+mgr._registerForInitialState(CheckerManager::CheckInitialStateFunc(checker, _checkInitialState));
+  }
+};
+
 } // end check namespace
 
 namespace eval {
Index: include/clang/StaticAnalyzer/Core/CheckerManager.h
===
--- include/clang/StaticAnalyzer/Core/CheckerManager.h	(revision 254233)
+++ include/clang/StaticAnalyzer/Core/CheckerManager.h	(working copy)
@@ -44,6 +44,7 @@
   struct NodeBuilderContext;
   class MemRegion;
   class SymbolReaper;
+  class EntryPointInfo;
 
 template  class CheckerFn;
 
@@ -387,6 +388,14 @@
   void runCheckersForPrintState(raw_ostream &Out, ProgramStateRef State,
 const char *NL, const char *Sep);
 
+  /// \brief Run checkers for manipulating the initial program state at the
+  /// start of the analysis.
+  ///
+  /// \param D AST node of entry point
+  /// \param State Initial program state
+  /// \returns Checkers can modify the state by returning a new one.
+  ProgramStateRef runCheckersForInitialState(const Decl *D, ProgramStateRef State);
+
 //===--===//
 // Internal registration functions for AST traversing.
 //===--===//
@@ -464,6 +473,9 @@
   AnalysisManager&, BugReporter &)>
   CheckEndOfTranslationUnit;
 
+  typedef CheckerFn
+  CheckInitialStateFunc;
+
   typedef bool (*HandlesStmtFunc)(const Stmt *D);
   void _registerForPreStmt(CheckStmtFunc checkfn,
HandlesStmtFunc isForStmtFn);
@@ -505,6 +517,8 @@
 
   void _registerForEndOfTranslationUnit(CheckEndOfTranslationUnit checkfn);
 
+  void _registerForInitialState(CheckInitialStateFunc checkfn);
+
 //===--===//
 // Internal registration functions for events.
 //===--===//
@@ -615,6 +629,8 @@
 
   std::vector EndOfTranslationUnitCheckers;
 
+  std::vector InitialStateCheckers;
+
   struct EventInfo {
 SmallVector Checkers;
 bool HasDispatcher;
Index: include/clang/StaticAnalyzer/Core/PathSensitive/EntryPointInfo.h
===
--- include/clang/StaticAnalyzer/Core/PathSensitive/EntryPointInfo.h	(revision 0)
+++ include/clang/StaticAnalyzer/Core/PathSensitive/EntryPointInfo.h	(working copy)
@@ -0,0 +1,50 @@
+//== EntryPointInfo.h - Entry point information *- C++ -*--=//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+//
+//  This file defines EntryPointInfo.
+//
+

Re: [Static Analyzer] New checker hook: checkInitialState

2015-11-29 Thread Gabor Kozar via cfe-commits
+Jordan, Anna

---
Best regards,

Gábor 'ShdNx' Kozár http://gaborkozar.me



On Sat, Nov 28, 2015, at 22:52, Gabor Kozar via cfe-commits wrote:
> Hi,
>
> Once, long ago, I started working on this checker callback, but forgot
> about it. I have decided to finish it now. Original discussion:
> http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20131216/095565.html
>
> The motivation was (pipermail doesn't seem to have my original mail,
> for some reason):
>
>> I had an issue recently with the Static Analyzer [while implementing
>> a checker] that I wouldn't be able
 to detect when a function was entered - either through a call or
 serving as the entry point of the analysis. (I ended up using
 checkPreStmt and figuring out if we've been magically transported
 inside a function body and check the program state whether the
 necessary info was already recorded by checkPreCall. Not something I'd
 call nice by any means.)
>
> The attached patch creates a new checker hook, with the signature:
>
>> ProgramStateRef checkInitialState(const EntryPointInfo& EPInfo) /*
>> non-const */;
>
> EntryPointInfo is currently a very simple class containing a Decl* of
> the declaration being used as an entry point and a ProgramStateRef of
> the initial state.
>
> Checkers implementing this hook can make changes to the program state
> by returning a new one. They are also allowed to return nullptr, in
> which case the analysis doesn't proceed further from that entry point.
>
> Please let me know what you think!
>
> ---
> Best regards,
>
> Gábor 'ShdNx' Kozár http://gaborkozar.me
>
>
> _
> cfe-commits mailing list cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits Email had 1
> attachment:


>  * clangsa_checkinitial.patch  11k (text/x-patch)
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


Re: [Static Analyzer] New checker hook: checkInitialState

2015-11-30 Thread Gabor Kozar via cfe-commits
This patch proposal is now on Phabricator: http://reviews.llvm.org/D15090 - 
let's continue this discussion there.

> At a glance, I wonder if it's worth it to provide a CheckerContext
inside this callback and then handle transitions properly (which would
allow the checker to split the program state at the very beginning of
the function). I cannot instantly think of a use-case (hmm, maybe
somebody would like to eagerly discriminate between a NULL and non-NULL
pointer argument of the function), but at the same time I don't see any
obvious problems with adding it, especially because it'd be hard to
change the API when the use-case appears.

Artem: thanks for your comment! I've added it to the Phabricator
summary, along with my reaction to it. I think your proposal is good,
I've started working on implementing it, but I also want to hear what
others (Anna, Jordan) think.

---
Best regards,

Gábor 'ShdNx' Kozár http://gaborkozar.me



On Mon, Nov 30, 2015, at 16:38, Artem Dergachev via cfe-commits wrote:
> Hmm. I once thought about creating a 'checkBeginAnalysis()' callback
> to match 'checkEndAnalysis()'; this one's more powerful, and matches
> 'checkEndFunction()' in a similar manner.
>
> At a glance, I wonder if it's worth it to provide a CheckerContext
> inside this callback and then handle transitions properly (which would
> allow the checker to split the program state at the very beginning of
> the function). I cannot instantly think of a use-case (hmm, maybe
> somebody would like to eagerly discriminate between a NULL and non-
> NULL pointer argument of the function), but at the same time I don't
> see any obvious problems with adding it, especially because it'd be
> hard to change the API when the use-case appears.
> _
> cfe-commits mailing list cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits