[cfe-dev] clang-refactoring tool proposal

[Eric Liu via cfe-dev]

Great idea! And I like the idea of having the tool being a Swiss army knife
like git.

I am currently working on a refactoring tool that move class/function
definitions across namespaces, and I think the tool can also live under the
"clang-refactor" umbrella!

Besides designing the easily extensible interfaces, another interesting
problem would be designing infrastructure for multi-TU changes IMO.

Cheers,
Eric
On Tue, Aug 9, 2016 at 7:32 PM Kirill Bobyrev via cfe-dev <
cfe-dev at lists.llvm.org> wrote:

> Oops, didn’t actually CC people.
>
> +CC: Saleem Abdulrasool, Manuel Klimek, Alexander Kornienko
>
> On 09 Aug 2016, at 19:27, Piotr Padlewski via cfe-dev <
> cfe-dev at lists.llvm.org> wrote:
>
> I think that clang-refactor is a good idea.
>
> On Tue, Aug 9, 2016 at 8:52 AM, Kirill Bobyrev via cfe-dev <
> cfe-dev at lists.llvm.org> wrote:
>
>> Thanks to Saleem Abdulrasool for originally proposing this approach in
>> the mentioned discussion.
>> +CC: Saleem Abdulrasool
>>
>> On Tue, Aug 9, 2016 at 2:07 PM, Kirill Bobyrev <kbobyrev at google.com>
>> wrote:
>>
>>> Hi everyone!
>>>
>>> As you know we have several useful Clang-based tools: clang-format for
>>> code formatting, clang-tidy for for diagnosing and fixing typical
>>> programming errors, clang-include-fixer for automatic management of
>>> #include directives and a few others.
>>>
>>> I am working on clang-rename, whose purpose is to perform efficient
>>> renaming actions in large-scale projects such as renaming classes,
>>> functions, variables, arguments, namespaces etc. It is clearly meant for
>>> refactoring code and doesn’t fit into any of above mentioned tools. And at
>>> this point we only have clang-rename for code refactoring.
>>>
>>> However, there are many other interesting refactoring actions, which are
>>> typically provided by third-party editor plugins or IDEs (and which we
>>> ideally would like to have), such as:
>>>
>>> * Extract method
>>> * Inline local variable, method or constant
>>> * Change method signature
>>>
>>> And many others. For a sample list of some popular refactoring
>>> techniques see Eclipse Refactorings list (
>>> http://help.eclipse.org/neon/index.jsp?topic=%2Forg.eclipse.jdt.doc.user%2Freference%2Fref-menu-refactor.htm)
>>> and ReSharper C++ Refactoring (
>>> https://www.jetbrains.com/resharper-cpp/features/#refactorings).
>>>
>>> We recently had a related short discussion in
>>> https://reviews.llvm.org/D23279, which introduced a simple tool for
>>> field reordering. The main point is that neither clang-rename nor
>>> clang-tidy are a good place for such a tool, but we don’t want to end up
>>> with too many binaries in clang-tools-extra, too.
>>>
>>> My proposed solution is to create clang-refactor tool, which would be an
>>> “umbrella” for other refactoring modules. A prototype of clang-refactor
>>> would merge clang-rename inside of it and other modules and refactorings
>>> would be added later.
>>>
>>> A properly designed clang-refactor tool would be able to process
>>> multiple Translation Units, which is crucial for all mentioned refactorings.
>>>
>>> I am very excited about the idea of having Clang-based refactoring tool
>>> and I see a lot of potential in it.
>>>
>>> I want to bring up a Community discussion and get feedback on these
>>> ideas.
>>>
>>> Best regards,
>>> Kirill Bobyrev
>>>
>>
>>
>>
>> --
>> Best regards,
>> Kirill Bobyrev
>>
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>
>>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20160810/3a66f1b7/attachment.html>