KDE/kdevelop/languages/cpp/cppduchain

[Hamish Rodda]

(Moving to kdevelop-devel)

On Tuesday 17 June 2008 20:34:14 David Nolden wrote:
> Am Dienstag, 17. Juni 2008 11:36:22 schrieb Hamish Rodda:
> > SVN commit 821376 by rodda:
> >
> > Make the openContext* functions generic
>
> I'm a bit worried about this commit, because this touches code that is
> really very C++ specific and fragile, and making those functions generic
> might make it complicated fixing bugs within the C++ support in future.
> Also I'm frightened of hard to find regressions, because especially the
> code updating hard to debug. But this is just from the commit messages, no
> time to look at the actual code atm.

I understand that, and of course c++ is the highest priority language.  
However what I am doing is really just re-merging the generic parts of the 
duchain builders which I've discovered through creating the java duchain.  
It's way too much code duplication to just let it bit rot in probably more 
than 5 locations, which every other language will face if this code is kept 
separated (already, the code was copied from c++ to java, to php).  I'm more 
than happy to track down any regressions which are found.

This will also lower the barrier to entry for further language support, which 
previously was too high.

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?

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

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.

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?  That 
will work fine with the current setup.  (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?)

Cheers,
Hamish.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20080617/c00c35a1/attachment.html>