================ Comment at: include/clang/StaticAnalyzer/Core/PathSensitive/CallEvent.h:127-129 @@ -126,4 +126,5 @@ protected: + const Stmt *TStmt; // This is user data for subclasses. const void *Data; ---------------- Karthik Bhat wrote: > Jordan Rose wrote: > > I really don't want to increase the size of CallEvent. How about using > > `Origin` to either represent a CXXDestructorDecl or a CXXDeleteExpr? > Hi Jordan, > Origin already contains CXXDestructorDecl hence CallEvent->getDecl() will > return CXXDestructorDecl but we will not be able to get the CXXDeleteExpr > which triggered it. > CXXDeleteExpr is required while reporting warning in MallocChecker as we are > checking if argument to delete is already deleted or not. > If we try to save CXXDeleteExpr in Origin instead then we are will face > problem when we try to inline code inside destructor call as > CallEvent->getDecl() will be null in this case. > > I assume Origin can have only 1 info at a time i.e. either Decl* or Expr* but > in this case we might need both. Hence added a new Stmt to represent the > triggered stmt. > > I'm still trying to get a hold of clang SA code so please let me know if i'm > wrong somewere or if there is some way to extract CXXDeleteExpr from > CXXDestructorDecl. I tried to have a look but couldnt find one. Since the CXXDeleteExpr already contains a reference to the CXXDestructorDecl, I think we can get this to work. (That's how CFGDeleteDtor works, right?)
It might make sense to make a completely new kind of CallEvent as well, rather than switching on whether the origin is a CXXDeleteExpr or a CXXDestructorDecl. The point of CallEvent is to abstract over the various ways a call can be written. I haven't thought this through, though—it might be more trouble than it's worth. http://llvm-reviews.chandlerc.com/D2441 _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
