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

[章磊]

Hi Ted,

My goal is to check whether there is a virtual call (directly or indirectly)
in construction or destruction.

In my former patch i do this check to all the constructors and the
destructor in checkASTDecl(const CXXRecordDecl ...). My way is walk through
the ast body of ctor/dtor: if there is virtual call, warn it; if there is a
call, walk through the callee's body recursively.

I think it's ok to do this check without the analysis engine and the inline
IPA.

What you say?
在 2011年9月26日 下午9:37，Ted Kremenek <kremenek at apple.com>写道：

>   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.
>
>
>


-- 
Best regards!

Lei Zhang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20110927/aa6a2f27/attachment.html>