[cfe-dev] clang-refactoring tool proposal

[Eric Liu via cfe-dev]

But the multi-TU support does not have to come from clang-refactor though,
it could be an infrastructure that clang-refactor or any other clang tools
can make use of.

On Wed, Aug 10, 2016 at 12:43 PM Kirill Bobyrev <kbobyrev at google.com> wrote:

> On Wed, Aug 10, 2016 at 12:32 PM, Eric Liu <ioeric at google.com> wrote:
>
>> 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!
>>
>> That's also a very nice thing to have!
>
>> Besides designing the easily extensible interfaces, another interesting
>> problem would be designing infrastructure for multi-TU changes IMO.
>>
>> Yes, that is true. For most refactoring actions I am considering multi-TU
> support is really important (starting from clang-rename).
>
>> Cheers,
>> Eric
>>
> Thank you for the feedback!
>
>> 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
>>>
>>
>
>
> --
> Best regards,
> Kirill Bobyrev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20160810/fb5d3461/attachment.html>