Refactoring features in KDevelop
d82ks8djf82msd83hf8sc02lqb5gh5 at gmail.com
Mon Feb 23 00:18:17 UTC 2015
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
> ... -> 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
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
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
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?
More information about the KDevelop-devel