clang-refactoring tool proposal

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

Thanks to Saleem Abdulrasool for originally proposing this approach in the mentioned discussion.
+CC: Saleem Abdulrasool

I think that clang-refactor is a good idea.

Oops, didn’t actually CC people.

+CC: Saleem Abdulrasool, Manuel Klimek, Alexander Kornienko

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

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!

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.

[Please reply *only* to the list and do not include my email directly
in the To: or Cc: of your reply; otherwise I will not see your reply.
Thanks.]

In article <CADzimdB7gFyZadkE=9-Z7TxWAAmjSUAKdd_+nqeM=o803-0mOg@mail.gmail.com>,
    Kirill Bobyrev via cfe-dev <cfe-dev@lists.llvm.org> writes:

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.

Sounds good to me. I've been adding refactoring tooling to
clang-tidy because that's where I was told it should go. You might
want to see about adding a mechanism to consume clang-tidy checks
into your refactoring tool.

You should consult my refactoring test suite:
<https://github.com/legalizeadulthood/refactor-test-suite>

It has ~100 test cases for rename alone.