[cfe-dev] Check virtual calls in ctor or dtor

[Ted Kremenek]

On Sep 25, 2011, at 2:32 AM, 章磊 wrote:

> Hi Ted,
> 
> I tried to implement this as a compiler warning. But i had some
> problem in how to get the body of the ctor or dtor.
> 
> I implemented this in Sema::CheckConstructor and
> Sema::CheckDestructor, but i can not get the body of them when there
> is no body with the declaration yet.

The idea how I thought this would be implemented was to do the analysis when processing CallExprs as we are building them.  We should know up front when we are about to process a constructor body.  Simply set/clear a Sema flag when processing the constructor body, and your check can consult that flag when processing a CallExpr to see if it needs to do the check.  Alternatively, checking the DeclContext may be all that is needed to see if we are currently in a constructor body.

The advantage of this approach is that it keeps all the checking local.  Walking the AST of a constructor body *after* we have constructed it is slow, and not really a great approach for doing compiler warnings in the frontend (if we can at all help it).

> And i also need the function body
> of the CallExpr in the ctor/dtor to do recursive analysis.

Interesting.  If your goal is to do inter procedural analysis, then this should remain a static analyzer check, or that should be a case caught beyond what a compiler warning should do.  That wasn't clear to me before that this was something you wanted to do.

The tradeoffs between compiler and static analyzer warnings are fairly simple:

1) Compiler warnings have higher visibility because all users see them all the time when building their code.

2) The logic behind compiler warnings must be as fast as possible.  Inter-procedural analysis is usually a show stopper, and ideally the checks are highly local.  Sema is already "walking" all of the code as it builds the AST, so often the warning logic can be put in key places, essentially where the warning would be issued.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20110926/f30920e3/attachment.html>