<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Oct 29, 2012, at 17:39 , Eli Friedman <<a href="mailto:eli.friedman@gmail.com">eli.friedman@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">On Mon, Oct 29, 2012 at 5:29 PM, Jordan Rose <<a href="mailto:jordan_rose@apple.com">jordan_rose@apple.com</a>> wrote:<br><blockquote type="cite"><br>On Oct 29, 2012, at 17:23 , Eli Friedman <<a href="mailto:eli.friedman@gmail.com">eli.friedman@gmail.com</a>> wrote:<br><br>Since the CFG is a linearized structure now, it's not printing CFG structure. Instead, it's trying to show the statement associated with a single CFGElement, such as a cast, in a way that you could match it up with the source but still see the evaluation pattern.<br></blockquote><br>So we're printing what basically amounts to a derived analysis for all<br>users? I guess that makes sense, to some extent... but is there no<br>way to formally query the CFGElements a given CFGElement depends on?<br></blockquote><div><br></div><div>In addition to Ted's response, I want to point out that the current dump may use placeholders for things the current element does <i>not</i> depend on for evaluation, e.g. a MemberExpr for a static member. Likewise, it may miss things that <i>are</i> dependencies: the semantic form of a PseudoObjectExpr. It's not a perfect format by any means...</div><div><br></div><br><blockquote type="cite"><blockquote type="cite">It is deliberately trying to print the syntactic ("pretty") form of the statement, but with placeholders for subexpressions that appear earlier in the CFG. Maybe these two goals are incompatible, but I can say that what we have has really helped us on the analyzer side.<br></blockquote><br>The issue comes down to the fact that you're trying to "pretty-print"<br>things which aren't actually written in the source. Maybe we need a<br>PrintingPolicy bit for not-so-pretty-printing?<br></blockquote></div><br><div>...and that does seem like we're venturing outside the intent of pretty-print, huh. I don't like the new form either, though, because it's even worse about implying that a given CFGElement is not consumed.</div><div><br></div><div>If you're okay with adding a PrintImplicitNodes bit to PrintingPolicy that would be good enough for us. Otherwise we'll have to think of something else.</div><div><br></div><div>Jordan</div></body></html>