Refactoring features in KDevelop

[Maciej Poleski]

Dnia czwartek, 29 stycznia 2015 11:53:04 Kevin Funk pisze:
> On Wednesday 28 January 2015 23:22:39 Milian Wolff wrote:
> > On Wednesday 28 January 2015 17:10:54 Maciej Poleski wrote:
> > > Hello
> > > 
> > > I was looking for C++ IDE capable of doing (at least partially
> > > automated)
> > > source code refactoring for years. Without success. I have Idea to
> > > implement some refactoring tools in KDevelop. What would You say about
> > > that? I know there is GSoC coming on and this seems be quite nice
> > > project.
> > 
> > Yes, this would indeed be an extremely interesting project. Note though,
> > that we want potential students to get active before the GSoC period, to
> > show their capabilities. Thus, if you want to work on this over the
> > summer,
> > you should get started *now*.
> > 
> > A good idea would be to get a list of goals, i.e. refactoring features
> > that
> > you want to implement. Then, you'll need to get your hands dirty with
> > kdev-
> > clang in the master branch, i.e. also build kdevplatform and kdevelop from
> > sources and against KDE frameworks 5 and Qt 5. Then try to figure out how
> > to add refactoring capabilities there. Start by porting existing features
> > from our old C++ language plugin over to kdev-clang, e.g. the ability to
> > de-inline a function in a header by moving its implementation to the
> > accompanying .cpp file.

My (personal) goals are:
 - Provide functionality capable of working on different codebases. I want this 
solution to work on any kind of (C++ see below) code that KDevelops' build 
system is capable of handling (with strong emphasis on CMake projects, but it 
would be nice if Makefile based projects and other would also be supported).
 - Work with big codebases. The need for a refactoring tools is proportional 
to size of codebase. The bigger project is the more automation is needed. The 
problem is with limited resources (memory) we can use for task.
 - Provide reasonable integration with IDE. Refactoring consists of making 
some arrangements, reviewing possible results and finally committing changes. 
The process might yield some additional issues which have to be consulted with 
user (programmer). These tools need neat integration with UI. It also means 
they shouldn't decrease responsiveness of IDE.
 - Provide solid solution. If this tool is to be useful for community it must 
be, be stable and reliable. Making unfinished tool usable only by few 
developers working on this and similar projects is not a solution. It must 
also provide reliable functionality. All code changes applied by tool must not 
break code. I prefer to forgo some functionality and concentrate on solid base 
rather than providing poor tool which only seem to work.

Refactoring features (atoms) (sketch):
 - rename (type, function, field, object)
 - move (function, object, ...)
   - also up/down in OOP
   - at least utility functions (without implicit dependencies on scope)
 - change signature (add new parameters, remove existing parameters, change 
order, static <-> instance, templates?...)
   - forward and inline
   - as default parameters
 - encapsulate (field, ...) (add middleman)
 - inline (function, ...) (remove middleman)
 - extract (piece of expressions (as a new function), piece of declarations 
(as a new class/namespace), ...)
 - change kind (namespace <-> class)
 - flatten (inline content of some scope into another scope)

more advanced:
 - generify (in fact templatize)
 - abstract (use base class where possible)

My main focus is on C++, but maybe some of these features can reasonably be 
provided also for C...

In fact I'm sure implementing all of these features is almost impossible, but 
I would take a try and implement at least the most useful ones. With stable 
base it would be good starting point for future improvements.

> 
> Yep. That would be my plan as well.
> 
> I didn't manage to come to refactoring tools during *my* GSoC last year, so
> this would be a nice continuation of the Clang integration work in KDevelop.
> 
> Start off by checking out libTooling of Clang:
> http://clang.llvm.org/docs/LibTooling.html
> 
> Unfortunately that's pure C++, more low-level, and not as stable as the C
> interface of libclang -- [1] indicates that people would be happy if you'd
> expose more interfaces in libclang in order to make it inter-operable with
> libTooling.
> 
> Happy to help out if you're interested in this area.
> 
> [1] http://lists.cs.uiuc.edu/pipermail/cfe-dev/2013-December/034304.html
> 
> > Overall, it would be a good idea to figure out how one could potentially
> > leverage the existing clang refactoring tools from our existing codebase.
> > The problem is that, afaik, these are all inaccessible via the C API we
> > use.
> > 
> > Bye

libTooling from Clang at this point of time seems to be the one way to do 
that. Decision seems be obvious. Unfortunately my knowledge about libTooling 
consists mainly of tutorials found on the Internet. I will have to improve 
that. I will also attend Compilers course (on my University) which will also 
have something to do with LLVM.

If You have any Ideas or doubts don't hesitate to discuss them. If You think 
that there is something important which I missed don't hesitate to tell. I 
will appreciate any help on this subject. 

Best Regards
Maciej Poleski