[cfe-dev] Where to put upcoming refcatoring tools

[Manuel Klimek]

On Tue, Apr 17, 2012 at 12:48 PM, Stephen Kelly <steveire at gmail.com> wrote:
> Manuel Klimek wrote:
>
>> On Mon, Apr 16, 2012 at 10:29 PM, Stephen Kelly
>> <steveire at gmail.com> wrote:
>>> Manuel Klimek wrote:
>>>
>>>> Hi guys,
>>>>
>>>> I'm remembering discussions about which set of tools we want to be in
>>>> the clang mainline, and for which we might want to create a new
>>>> project.
>>>> Since the tooling base has landed now, I'd like to get some idea of
>>>> how we're planning to structure the clang based tools in the code
>>>> base, so we have clear guidelines for the future.
>>>>
>>>> It seems like on the one hand there's clang-check, which is so closely
>>>> coupled to clang itself that my gut feeling is it fits perfectly into
>>>> the clang mainline.
>>>> On the other side we have things like 'clang-extract-method', which
>>>> we'll probably not want in clang mainline.
>>>> In between there are things like clang-format, which basically all
>>>> tools that do code changes will depend upon, thus it's still pretty
>>>> close to clang, so we might want to put that into mainline, but I'm
>>>> not sure.
>>>>
>>>> My proposal would be to create a new top-level llvm project for the
>>>> refactoring tools with a clear guideline on what would go in there.
>>>>
>>>> Thoughts?
>>>>
>>>> Thanks,
>>>> /Manuel
>>>
>>>
>>> Did anything come of this? I'm trying to find out how to write a clang
>>> C++ rewriting tool.
>>
>> Not yet. Currently the majority of the refactoring infrastructure
>> (besides the basic tooling support) is in a branch in
>> ^cfe/branches/tooling. There are ways to write rewrite tools based on
>> what's in mainline, it just requires a little more busy work on your
>> side.
>
> That doesn't seem to be in the git repo as far as I can tell. However, I
> checked out an old revision which has the ReplaceCStrCalls tool, and I read
> through the MatchFinder API yesterday. I haven't tried it out yet though. I
> presume that's what's in the branch?

The MatchFinder API and the RefactoringTool API
(include/clang/Tooling/Refactoring.h).

The MatchFinder API would be useful in your case to find the cases you
want to rewrite. The RefactoringTool API makes it possible to run over
many TUs in one process and reply all the edits after deduplicating
them, leaving your repository in a compilable state.

The ReplaceCStrCalls example is definitely the best one we currently
have for refactorings.

>
>>
>> Out of curiosity: what kind of rewriting tool are you planning to
>> implement?
>
> I'm interested in automated semantic porting from Qt 4 to Qt 5 (I'm a KDE
> contributor and Qt consultant with KDAB).
>
> To try out the tool, my first goal is to be able to port
>
> namespace Qt {
> QString escape(const QString &input);
> }
>
> which is deprecated in Qt 5 and should be replaced with a use of
>
> class QString {
>  ...
>  QString toHtmlEscaped() const;
> };
>
>
> It gets interesting because there are several implicit constructors for
> QString.
>
> Qt::escape("foo");
>
> needs to be changed to
>
> QString::fromLatin1("foo").toHtmlEscaped();
>
> or one of several other constructs for creating QStrings.
>
> Then there are things like
>
> Qt::escape(someAPIReturningQString());
>
> which should be
>
> someAPIReturningQString().toHtmlEscaped();
>
> and
>
> Qt::escape(someAPIReturningQByteArray());
>
> (or APIs returning a const char * for example)
>
> which would need to be ported to:
>
> QString::fromLatin1(someAPIReturningQByteArray()).toHtmlEscaped();
>
> (the implicit conversion from QByteArray to QString uses a latin1 codec)
>
> That is, the porting tool which finds a use of Qt::escape needs to know if
> the QString argument is the result of an implicit cast or not. There are
> many other porting cases in Qt 4 to 5 where implicit casts are involved, or
> which would benefit from semantic porting rather than python or sed scripts.
>
> There are also similar cases to deal with in porting KDE applications.
>
>
> Let me know if you have any tips or guidance on how to get started. I'm
> hoping the example here
> http://thread.gmane.org/gmane.comp.compilers.llvm.bugs/17991 which looks
> compilable will lead me to figure out how to add in-place rewriting to the
> tool.

This is exactly the example our tooling / ASTMatcher infrastructure is
written for (and we have similar examples we do internally for our
APIs). If you want to try to put up a tool based on the tooling
branch, feel free to contact me when you need help or have feedback on
the APIs.

Cheers,
/Manuel

>
> Thanks,
>
> Steve.
>
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev