<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Jul 10, 2011, at 2:41 AM, Chandler Carruth wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div class="gmail_quote">On Fri, Jul 8, 2011 at 10:24 AM, Argyrios Kyrtzidis <span dir="ltr"><<a href="mailto:kyrtzidis@apple.com">kyrtzidis@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div style="word-wrap:break-word"><div><div><div></div><div class="h5"><div>On Jul 8, 2011, at 10:03 AM, Chandler Carruth wrote:</div><br><blockquote type="cite"><div class="gmail_quote">On Fri, Jul 8, 2011 at 8:16 AM, Douglas Gregor <span dir="ltr"><<a href="mailto:dgregor@apple.com" target="_blank" class="cremed">dgregor@apple.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Agreed on all points.</blockquote></div><br><div>Thoughts on my second question (that of the names used in the actual code of Clang)? I'll start on fixing the diagnostics based on this plan today.</div></blockquote><div>
<br></div></div></div><div>I like the whole proposal, and having the name change reflected in clang source code would be ideal, thanks for your work!</div></div></div></blockquote><div><br></div><div>Cool, here is the first patch which just changes the word in the diagnostics (none of the fancy new diagnostics I'd like to get to yet...) and the first 4 patches in moving the code over. This moves essentially all of the code local to the preprocessor and the diagnostic printer over. How is this looking?</div></div></blockquote><div><br></div><div>They all look good to me.</div><br><blockquote type="cite"><div class="gmail_quote"><div>Can I rely on post-commit review for the rest of the terminology switch? That would be really useful as several of those are going to be massive, but entirely mechanical patches (SourceManager cleanup... ugh…).</div></div></blockquote><div><br></div>Yes, post-commit review is fine.</div><div><br><blockquote type="cite"><div class="gmail_quote"><div>Do we want to add the new terms to libclang's C interface? (they're currently only used for the names of enums, so we should be able to leave the old names in with the same value for compatibility)</div></div></blockquote><div><br></div><div>Yes, it makes sense to add these new terms to libclang's C interface, so long as we keep the old ones in place.</div><br><blockquote type="cite"><div class="gmail_quote"><div>Finally, the change to introduce the more detailed note diagnostic text will require a bit of re-working the infrastructure in TextDiagnosticPrinter. I'd like to generally refactor how some of that file is implemented. Can I just commit those refactorings, and then the changes to implement the new functionality, or would you like pre-commit review there? (I'm fine either way, just trying to plan out my work.)</div>
</div></blockquote><br></div><div>Refactoring in TextDiagnosticPrinter seems like something that can be post-commit reviewed.</div><div><br></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>- Doug</div><br></body></html>