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

[Matthew Plant]

For template specialization the renaming tool would have to generate code,
which is a little beyond what I would want a renaming tool to do, and
determine which type to specialize to, which could quickly become a very
complicated problem.


On Tue, Jul 29, 2014 at 5:22 PM, Eugene Ostroukhov <eostroukhov at gmail.com>
wrote:

> 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
>>
>>
>
> _______________________________________________
> 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/a6ee9b9f/attachment.html>