[cfe-dev] RFC: Adding a rename refactoring tool to clang
Gabriel Dos Reis
gdr at integrable-solutions.net
Fri Aug 1 13:22:03 PDT 2014
On Wed, Jul 30, 2014 at 9:42 AM, Richard <legalize at xmission.com> 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
> > 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.
not to be argumentative, but in what ways is Clang's parser not ad-hoc and
homegrown? How many C++ parsers aren't in that category?
> 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
> 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.
JetBeans has been promising:
It would be interesting to see the two of you sort it out on that kind of
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the cfe-dev