Committed with the style tweaks we discussed in person in r134904.<br><br><div class="gmail_quote">On Mon, Jun 27, 2011 at 2:31 PM, Richard Trieu <span dir="ltr"><<a href="mailto:rtrieu@google.com">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;">Ping.<div><div></div><div class="h5"><br><br><div class="gmail_quote">On Tue, Jun 21, 2011 at 4:50 PM, Richard Trieu <span dir="ltr"><<a href="mailto:rtrieu@google.com" target="_blank" class="cremed">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">
Instead of passing around an enum, a vector of QualTypes is passed into the function where the aka strings are generated.  This should be the latest that the comparisons can be held off.<div><div></div><div><br>
<br><div class="gmail_quote">On Thu, May 26, 2011 at 3:06 AM, Chandler Carruth <span dir="ltr"><<a href="mailto:chandlerc@google.com" target="_blank" class="cremed">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 Mon, Apr 25, 2011 at 8:38 PM, Richard Trieu <span dir="ltr"><<a href="mailto:rtrieu@google.com" target="_blank" class="cremed">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">
Ping.  Any comments on this patch?</blockquote><div><br></div></div><div>I like the general direction of this patch, but I have one nit, and one more serious comment.</div><div><br></div><div>nit: You should switch back to the enum for the ArgumentKind in your interface rather than exposing the raw 'char' storage type. This may be made irrelevant by the major comment though....</div>



<div><br></div><div>My big issue is similar to Sebastian's. This slows down the *building* of diagnostics. It would be much better to do all of this logic in the Diagnostic class.</div><div><br></div><div>To give a concrete reason, SFINAE: we sometimes build many many diagnostics merely to detect the presence of them, discard a particular type with those diagnostics, and then begin semantically analyzing something else. We don't want to pay for this type of formatting logic in that case. We only want to pay for it when we are *emitting* the diagnostic.</div>



<div><br></div><div>Another reason; after we've hit the max diagnostic emitted limit, it would be good to cut any and every corner we can to speed things up.</div><div><br></div><div>Finally, I think it will be more semantically clear. No need to funnel an enum through so many layers, etc.</div>



</div>
</blockquote></div><br>
</div></div></blockquote></div><br>
</div></div></blockquote></div><br>