Refactoring features in KDevelop

Fri Jan 30 17:58:21 UTC 2015

On Friday 30 January 2015 17:43:39 Maciej Poleski wrote:
> 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)

This is a nice list of features already. 

Add one more:
- Pimpl or even un-pimpl a class (this would be super useful)

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

I think most of them are surely possible *if you implement it properly* as AST 
Rewriter based on libTooling from Clang.

There are quite a few blog posts / papers describing how to do it, for 
instance:
  http://eli.thegreenplace.net/2014/05/01/modern-source-to-source-transformation-with-clang-and-libtooling/
  http://llvm.org/devmtg/2014-04/PDFs/Talks/NickRefactoring.pdf
  ... -> Google!

After reading through those you'll have a pretty good idea about the whole 
tooling aspect of Clang.

But as Milian said, right now it's the perfect time to dive into kdev-clang, 
libclang, and libTooling, to prepare a bit for your GSoC project and to show 
off your skills

Greets

> > 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
> 
> _______________________________________________
> KDevelop-devel mailing list
> KDevelop-devel at kde.org
> https://mail.kde.org/mailman/listinfo/kdevelop-devel

-- 
Kevin Funk | kfunk at kde.org | http://kfunk.org