<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, May 5, 2014 at 7:29 PM, Jordan Rose <span dir="ltr"><<a href="mailto:jordan_rose@apple.com" target="_blank">jordan_rose@apple.com</a>></span> wrote:<br>
<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"><br><div><div class=""><div>
On May 5, 2014, at 10:27 , Manuel Klimek <<a href="mailto:klimek@google.com" target="_blank">klimek@google.com</a>> wrote:</div><br><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">
On Mon, May 5, 2014 at 6:49 PM, Jordan Rose <span dir="ltr"><<a href="mailto:jordan_rose@apple.com" target="_blank">jordan_rose@apple.com</a>></span> wrote:<br>
<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>Neither of these are part of the analyzer; they're part of the analysis-based warnings in Clang. libClangAnalysis is the common base between the two, which is why we have to be careful about the CFG, but the full analyzer infrastructure isn't going to be the answer.</div>

</div></blockquote><div><br></div><div>What would be "full analyzer infrastructure" here? The <span style="font-size:13px;font-family:arial,sans-serif">REGISTER_MAP_WITH_</span><span style="font-size:13px;font-family:arial,sans-serif">PROGRAMSTATE part?</span></div>
</div></div></div></blockquote><div><br></div></div><div>ProgramState at all. The analysis-based warnings track their own state in more lightweight structures, and aren't usually following paths anyway.</div></div></div>
</blockquote><div><br></div><div>The consumed analysis seems to have to? Otherwise, how would it figure out that something was not consumed in all paths?</div><div><br></div><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 class=""><blockquote type="cite"><div dir="ltr"><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>"A new block may only be started if there is control flow" probably is not enforced, but I'm not sure why we wouldn't do that. ("control flow" doesn't have to mean a C/C++ notion of control flow; it can be something like the static variable DeclStmt that clients of the CFG can use to decide where execution goes next.)</div>

</div></blockquote><div><br></div><div>I'm aware control flow doesn't necessarily mean C/C++ control flow.</div><div>Here's my reasons why we might not want to have that invariant.</div><div>1. if I remember correctly I have already seen blocks that don't have terminators that just flow into a single other block (I'll try to fish one out if you're curious); so I was surprised to see other places basically assert in a comment that this is an assumed invariant</div>

<div>2. it seems that sometimes having the CFG be more uniform regarding different related patterns might be nice (although I see that it is a very very weak argument)</div><div>3. it might just be too hard to assert the invariant, in which case I'd say it's better to explicitly say it's *not* an invariant than to let checks or cfg-based compiler checks rely on it</div>
</div></div></div></blockquote><div><br></div></div><div>I guess it's not. After an if-statement, both branches have to transition to the same block, of course. I'm not sure what I was thinking, nor am I sure what the comment was getting at.</div>
</div></div></blockquote><div><br></div><div>Well, I thought "incoming" control flow (at the end of an if) is just part of control flow.</div><div><br></div><div>And I think I caused some confusion, as the invariant proposal I made was not actually a citation of the code (but might have looked like I implied that). </div>
<div>The comment is:</div><div><div>// Note also that we are restricting</div><div>// to looking at return statements in the same CFGBlock,</div><div>// so this will intentionally not catch cases where the</div><div>// return statement contains nested control-flow.</div>
</div><div><br></div><div>Which seems to imply that invariant, though?</div><div><br></div><div>Cheers,</div><div>/Manuel</div></div></div></div>