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

[Daniel Albuschat]

Hi,

2014-07-30 19:13 GMT+02:00 "C. Bergström" <cbergstrom at pathscale.com>:

> On 07/30/14 11:42 PM, Richard wrote:
>
>> This is where clang-based refactoring tools are really going to shine.
>> Leveraging the *production quality* parser and resulting lossless AST
>> just puts you miles ahead in the game.
>>
> Have you evaluated MSVC+Visually Assist plugin? While it's not IntelliJ, I
> have heard good things about it. I think that's a professional level
> baseline which other tools could work towards matching/beating..
>
> This is OT for the list, but you and others are welcome to follow-up with
> me offlist for the refactoring stuff we are doing where I work.
>
> The refactoring work I have experience with ends up relying on things
> which go sorta outside the typical libclang tooling realm. You really have
> a lot to track beyond just a single source file and dealing with that can
> get tricky.


I have much experience with refactoring large C++ codebases, all depending
on WinAPI. My conclusion is: Visual Assist X seems to currently be the best
tool at the market. However, it is quite useless, since most - if not any -
refactoring-attempts at an over 20-year-old codebase with roughly 2 million
lines of Microsoft-infested C++ code (DWORD, BOOL, etc.) failed. Even
small, local refactorings take a) very long and b) mostly yield incorrect
results.
For example, there was a paradigm to have a nested "data"-class inside of
classes that manage the ui. They all share the same name, albeit being
nested inside of totally different classes. VA X failed miserably analysing
("Go to definition") and refactoring this.

BTW, this is similar to Microsoft's effort regarding Roslyn: They already
understood that there can be no sufficiently functioning refactoring tool
that does not actually use the compiler's parser itself.

If clang-rename will be able to handle the codebase I am working with, I
will be in sheer joy.

Greetings,
Daniel Albuschat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20140731/e0513e7f/attachment.html>