Refactoring features in KDevelop

[Maciej Poleski]

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-transformat
> 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?

Best Regards
Maciej Poleski