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

[Eugene Ostroukhov]

Template specialization is also an option:

struct A { typedef int Goo; };
struct B { typedef char Foo; };
template<typename T> struct X { typename T::Foo bar; };
template<> struct X<A> { typename A::Goo bar; };
X<A> a;
X<B> b;



On Fri, Jul 25, 2014 at 1:23 PM, Richard Smith <richard at metafoo.co.uk>
wrote:

> On Fri, Jul 25, 2014 at 1:01 PM, Amin Shali <amshali at google.com> wrote:
>
>> 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.
>>
>
> Do you intend to provide one command-line tool per refactoring, or one
> tool that has subcommands for each operation? For command-line / scripting
> use, it'd seem useful to also be able to specify a symbol by name (at least
> for names that are not function-local). (For instance, say I want to rename
> all *Decl classes in clang to *Declaration. I'd like to be able to perform
> a semantic grep for those, then run them through a command-line rename
> tool.)
>
> 2- An API for doing the above task which can effectively be used to
>> provide this functionality for any editor (Emacs, Vim, CodeMirror, etc.).
>>
>> == Renaming capabilities
>> In the first iteration, we are offering the following features for the
>> rename refactoring:
>> === Supported C++ constructs:
>>          - Global and local variables (including function arguments)
>>          - Functions
>>          - C and CXX record types (structs/unions/classes)
>>            - For classes this includes renaming the constructor and
>> destructor
>>          - User defined types
>>          - Enumerations (names and constants)
>>          - Record member variables and methods
>>          - Namespace specifiers
>>          - Template parameters
>>          - Lambda captures
>>          - Overloaded operators
>> === Unsupported C++ constructs:
>>          - Macros
>>          - Symbols in comments
>>
>> == Command line program
>> === Current support:
>>          - Input from stdin, output to stdout
>>          - Input and output from/to disk
>>          - Option to specify include path
>>          - Option to predefine macros
>> === Possible improvements:
>>          - Multiple files from stdin
>>          - Making backups of renamed files
>>
>> We think this tool should reside in clang-tools-extra.
>>
>> Please let us know what you think. Any comment and feedback is
>> appreciated.
>>
>
> Do you have any thoughts on how to handle templates? For instance:
>
> struct A { typedef int Foo; };
> struct B { typedef char Foo; };
> template<typename T> struct X { typename T::Foo bar; };
> X<A> a;
> X<B> b;
>
> Suppose we want to rename A::Foo to A::Goo. Our obvious choices are:
> 1) Don't rename the use inside X; breaks X<A>.
> 2) Do rename the use inside X; breaks X<B>.
> 3) Rename the use inside X and the use inside B; will surprise users.
> 4) Report an error and refuse to rename A::Foo. Tell users they need to
> rename B::Foo too. (And if the user requests that both are renamed at the
> same time, do the right thing.)
>
> I think option 4 is the best choice, but it might be a little tricky to
> get right.
>
> How do you intend to behave when renaming an entity shared by multiple
> source files? That might influence the checks you're able to perform for
> the above case.
>
> _______________________________________________
> 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/20140729/bc9657ab/attachment.html>