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

["C. Bergström"]

On 07/30/14 11:42 PM, Richard wrote:
> In article <CAMfx8+eLTwdAbHw64L-O71hChrsKJKBOsgB-cuYaXN4xU7Qp5Q at mail.gmail.com>,
>      Matthew Plant <mplant at google.com> writes:
>
>> The code does not need to be compile-able, but it does need to be at least
>> some-what parseable.
> In this regard, clang's rename won't be any worse than any other
> language's rename.
>
> For instance, refactoring tools are pretty mature in .NET/Java, but
> none of them successfully rename an identifier whose type can't be parsed.
> You're fundamentally missing the semantic information needed to decide
> where else this identifier needs to be changed.
>
> As far as C++ refactoring tools goes, *anything* based on clang's
> parser is going to be light years ahead of other tools that are based
> on ad-hoc homegrown parsers.  I've been kicking the tires of C++
> refactoring tools since roughly 2007 when I started refactoring a crusty
> old code base.  Obviously the older tools use their own parser.  Just
> having a parser that gets the job done correctly is difficult, never
> mind keeping that parser up to date with the C++11 and C++14
> standards.
>
> 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.