[cfe-dev] RFC: Adding a rename refactoring tool to clang

Matthew Plant mplant at google.com
Wed Jul 30 01:04:49 PDT 2014


Hey Daniel,

Thanks for your optimism! I sure hope it's prescient.

The code does not need to be compile-able, but it does need to be at least
some-what parseable. From what I've seen, some errors will not prevent
clang from building an AST, albeit an incomplete one. However, the renaming
tool will only be able to rename symbols that are contained in the AST, and
if the AST doesn't contain some symbols, perhaps because some includes were
missing and gosh darnit clang just has no idea what the heck is a DWORD??

Basically, in order for it to be renamed, a symbol must be understood by
clang. And how Clang works around various error conditions is beyond my
knowledge - you'll have to go check the source!

Incidentally, I seem to recall that there is a section in the dragon book
that talks about error recovery in parsers. I didn't read that section (or
book), but I imagine someone working on clang has.

I'm confident that did not answer your question entirely, so I apologize.

-Matt


On Wed, Jul 30, 2014 at 12:18 AM, Daniel Albuschat <d.albuschat at gmail.com>
wrote:

> Hi there,
>
> 2014-07-25 22:01 GMT+02:00 Amin Shali <amshali at google.com>:
>
>  Folks,
>>
>> At Google we are working on a tool and set of APIs for refactoring C++
>> programs based on LibTooling. Particularly, we have targeted rename
>> refactoring for C++ as our first step.
>>
>> In our first iteration we want to offer two things:
>> 1- A command line tool similar to clang-format which will semantically
>> rename a symbol (specified by a position in a file) in a set of input files.
>> 2- An API for doing the above task which can effectively be used to
>> provide this functionality for any editor (Emacs, Vim, CodeMirror, etc.).
>>
>
> This is something that C++ developers are definitely lacking. Just image
> how neat it could be to rename some legacy class or method name in the LLVM
> or clang codebase that has been bugging you ever since. :-) If it can be
> used broadly, it could become a "game changer" in C/Objective C/C++ code
> quality, e.g. for large frameworks like Qt, KDE, the Linux kernel.
>
> I have one question that might be important to others that are interested,
> too:
> Will this only work on a codebase that can be compiled (or at least
> strictly parsed) with clang, or is it more "fuzzy", so it will work with
> e.g. a codebase that uses windows.h (that, afaik, can not be compiled with
> clang - please correct me if I'm wrong)?
> This might be a general LibTooling-question, though.
>
> Greetings,
>
> Daniel Albuschat
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20140730/b98d49b2/attachment.html>


More information about the cfe-dev mailing list