[cfe-dev] Switching terminology from 'instantiation' to 'expansion' for macros?

[Douglas Gregor]

On Jul 10, 2011, at 2:41 AM, Chandler Carruth wrote:

> On Fri, Jul 8, 2011 at 10:24 AM, Argyrios Kyrtzidis <kyrtzidis at apple.com> wrote:
> On Jul 8, 2011, at 10:03 AM, Chandler Carruth wrote:
> 
>> On Fri, Jul 8, 2011 at 8:16 AM, Douglas Gregor <dgregor at apple.com> wrote:
>> Agreed on all points.
>> 
>> 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.
> 
> I like the whole proposal, and having the name change reflected in clang source code would be ideal, thanks for your work!
> 
> 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?

They all look good to me.

> 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…).

Yes, post-commit review is fine.

> 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)

Yes, it makes sense to add these new terms to libclang's C interface, so long as we keep the old ones in place.

> 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.)

Refactoring in TextDiagnosticPrinter seems like something that can be post-commit reviewed.

	- Doug

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20110711/4e6e48aa/attachment.html>