<div class="gmail_quote">On Fri, Jun 1, 2012 at 3:09 PM, Richard Trieu <span dir="ltr"><<a href="mailto:rtrieu@google.com" target="_blank">rtrieu@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5"><div class="gmail_quote">On Wed, May 30, 2012 at 5:37 PM, Chandler Carruth <span dir="ltr"><<a href="mailto:chandlerc@google.com" target="_blank">chandlerc@google.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="gmail_quote"><div>On Fri, May 18, 2012 at 3:35 PM, Richard Trieu <span dir="ltr"><<a href="mailto:rtrieu@google.com" target="_blank">rtrieu@google.com</a>></span> wrote:<br></div><div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Update the uninitialized field checker to catch more cases of uninitialized use.  This will catch fields passed by value to function calls and properly parse conditional operators.  Instead of a recursive function, an EvaluatedExprVisitor will be used.
<br></blockquote><div><br></div></div><div>What's the compile-time impact of this? Maybe synthesize a test case with a crazy number of fields (all initialized) with long expressions in their initializers, and compare before and after? (There are some tests in INPUTS that you can model this after...)</div>

</div></blockquote><div> </div></div></div></div>Synthesized some test cases with 4096 classes, each class having a single field initializer with 2048 sub expressions.  My testing showed a 5-10% slow-down for the new EvaluatedExprVisitor compared to the current recursive function check.<br>

</blockquote></div><div><br></div>Ping.