[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
> 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.

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
> 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.
JetBeans has been promising:
It would be interesting to see the two of you sort it out on that kind of
field :-)

-- Gaby
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20140801/95a0b30a/attachment.html>

More information about the cfe-dev mailing list