KDE/kdevelop/languages/cpp/cppduchain

[David Nolden]

Am Dienstag, 17. Juni 2008 13:41:56 schrieb Hamish Rodda:
> I'm hoping that this process will make the code less fragile, and probably
> expose a few bugs along the way.  For example, of the various openContext
> varieties in c++, some call editor->findRange, and some call editor-
>
> >findRangeForContext; shouldn't they all be calling findRangeForContext?

Hmm yep that's probably true, unless that hack had a special reason.

> Refactoring will also make the code easier to understand, and to document
> for those working on the code.

I agree, I just fear that it will throw my effort to make the 
parsing "reliable" back a bit, because the count of bugs in C++ support is 
increased again instead of sinking constantly.

> Fixing bugs with the code should not be much harder than if all of the
> logic were in the one class as currently, in fact I think it is even a bit
> more object-oriented now given that the visitors are a bit more separated
> from the parser state.

It just won't be easily possible to fix problems in the C++ support without 
possibly breaking other languages.

> The only issue for working on the c++ support now is that you'll have to
> work with those files as well as the c++ specific files, and it is a little
> annoying that you have to install them before you compile kdevelop (and
> error messages open the installed include, that I consider a bug worth
> fixing, by using knowledge from the build system when we open files and
> preferentially opening the original source file not the installed version).
>
> > Also I'm planning to merge the use-builder and the
> > declaration/context-builder because the 2 iterations are too slow, so
> > please take that into account while generalizing. :)
>
> Ok, by layering on top the use builder onto the declaration builder?
Yes

> (Are you sure that it's not a 
> premature optimisation to do that, because most likely the persistent
> duchain store will make 90-99% of parsing happen only on rare occasions,
> right?)

I'd like to make use-building the default at some point, so it would be 
senseless having that additional run through the complete AST. And we will 
always be doing a lot of parsing, don't worry about that. For example when 
you change a header, you will have to reparse all the files that recursively 
include it, if the change was significant.

Anyway, in general I agree with you that generic code should be shared, but 
there is just cases where generalization makes everything more complicated 
then bringing a benefit(Having worked a lot on the DUChain I know what I'm 
talking about). Even the splitting between Context-/ Type-/ and 
Declaration-builder has sometimes been problematic, because they are not 
independent, and the way they interact is hard to track. Well, that's enough 
of whining for now. Let's better try fixing kdevelop. :)

Greetings, David