[cfe-dev] CFG support for temporary object desctructors

[Jordan Rose]

On Jul 2, 2013, at 6:20 , Pavel Labath <labath at google.com> wrote:

>> After reading this email, I took a look if it is possible to make the analyzer not inline temporary destructors. But I couldn't find a _nice_ way to do that. At the point where the inlining decision is made, I don't have access to the type of the destructor call. Obviously, I could  push information through somehow, but instead I decided to take another look at what happens when I actually do inline the destructors, since it already seems to be mostly working. I will try to fix the two issues I mentioned above (which means the CFG will get more testing and validation) and then you can decide whether the code is stable enough to be switched on. If I fail at that, I can always make the destructors opaque, as you suggested.
> 
> I would cheat a lot by asking if the destructor's region is a CXXTempObjectRegion, or perhaps "stack memory space but not a VarRegion". ;-)
> 
> On the other hand, your patch to NoReturnFunctionChecker is giving me more hope that it may be possible to solve the noreturn problem without fully implementing this feature.
> 
> Jordan
> 
> 
> After a couple of days of plowing through the code I'm not much smarter, only more convinced that this is really not easy, so I'm starting to agree with you that we should just not inline these calls (for now). I have tried adding a inlining test like:
>   if (const CXXDestructorCall *DC = dyn_cast<CXXDestructorCall>(&Call)) {
>     if (isa<CXXTempObjectRegion>(DC->getCXXThisVal().getAsRegion())) return false;
>   }
> 

Actually, hang on...wouldn't the case we care about go through ExprEngine::ProcessTemporaryDtor? It'd be a real hack, but you could check the current CFGElement and see if it's a CFGTemporaryDtor. (The current block is inside currBldrCtx and the index is currStmtIdx.)

Jordan

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