[cfe-dev] Where to put upcoming refcatoring tools

[Stephen Kelly]

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?

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

Thanks,

Steve.