Refactoring features in KDevelop

[Milian Wolff]

On Monday 23 February 2015 01:18:17 Maciej Poleski wrote:
> Dnia piątek, 30 stycznia 2015 18:58:21 piszesz:
> > 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-transforma
> > t
> > ion-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
> 
> Hello
> 
> It's almost month since my last message. What I achieved in short.
> 
> 1 Passed all exams (end of semester).
> 2 I tried "porting (...) the ability to de-inline a function in a header by
> moving its implementation to the accompanying .cpp file". Looked like quite
> simple and introductory task. It turned out to 6765 SLOC (still not
> finished!) patch consisting of code from around 2007 (part of oldcpp
> duchain). I stopped here because of two/three main points:
>  - What I was working on was in fact moving big pieces of old codebase into
> kdev-clang. I'm not sure if we really want to pull in that amount of old
> code into new plugin (duplicating some functionality from libClang).
>  - I would have to implement instantiate method(s) in ClangDuContext. As it
> looks like kdev-clang duchain is based on libClang and my work will focus on
> libTooling, probably that's not a way I should proceed.
>  - All of these is about DUChain. In fact I never before considered duchain
> as a foundation of refactoring capabilities. DUChain is some kind of
> abstraction. Refactoring will most likely (libTooling) require direct
> access to source code and simply disable possibility of such abstraction.
> For now I'm not even sure if it is possible to abstract storage (use
> document model instead of on-disk file).
> 
> In fact ability to move code from one place to another will be required for
> many refactoring features. It will have to be solved in the most general
> situation.
> 
> For now I have to work a bit with libTooling to see what can be done with
> that and come with more precise design.
> 
> What do You think about that? Is DUChain expected to provide refactoring
> capabilities or only some, not binding, idea of approach to refactoring? Is
> working on DUChain-based old refactoring capabilities worth spending time
> when at end We want/have to "escape" from DUChain?

I think the old codebase you tried to port is too strongly tied to the DUChain 
as that's what was available back then. Now, we can either use the Clang-C API 
directly or do anything else. So for e.g. doing the "move inline 
implementation to .cpp file" you'll need to do something like:

- for a given cursor location decide whether it belongs to an inline method.
there is existing code in kdev-clang to check whether a file is a header. then 
check, with the clang-c API, whether the cursor is in the body of a function.
- if that's the case, add/enable the refactoring action
see old code for how to do that, potentially clean it up in the porting 
process
- upon execution of the refactoring action, create the corresponding 
DocumentChangeSet with the text removal and addition.
here you'll need the range of the function body to remove, again something for 
the clang-c API. The text could be added for safety reasons but maybe it's OK 
to ignore this for now and leave it empty and disable the safety check.
- ensure you add plenty of unit tests for this

So in this case, there shouldn't be much use of the DUChain at all.

Bye, HTH. If you have more questions, shout!
-- 
Milian Wolff
mail at milianw.de
http://milianw.de