<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Jul 2, 2013, at 6:20 , Pavel Labath <<a href="mailto:labath@google.com">labath@google.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; "><div style="word-wrap: break-word; "><div><div><blockquote type="cite" style="font-family: Helvetica; font-size: medium; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>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.</div><div></div></div></div></div></blockquote><div style="font-family: Helvetica; font-size: medium; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><br></div></div><div>I would cheat a lot by asking if the destructor's region is a CXXTempObjectRegion, or perhaps "stack memory space but not a VarRegion". ;-)</div></div><br><div>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.</div><span><font color="#888888"><div><br></div><div>Jordan</div></font></span></div></blockquote></div><br></div><div class="gmail_extra"><br></div><div class="gmail_extra">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:</div><div class="gmail_extra"><div class="gmail_extra"> if (const CXXDestructorCall *DC = dyn_cast<CXXDestructorCall>(&Call)) {</div><div class="gmail_extra"> if (isa<CXXTempObjectRegion>(DC->getCXXThisVal().getAsRegion())) return false;</div><div class="gmail_extra"> }</div></div></div></div><br class="Apple-interchange-newline"></blockquote><br></div><div>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.)</div><div><br></div><div>Jordan</div><br></body></html>