C++ support questions

[David Nolden]

2011/2/7 Milian Wolff <mail at milianw.de>:
> Hey David,
>
> and probably also Dmitry as you wanted to have something to work on ;-)
>
> On the weekend I (shortly) investigated the two main issues that bug me with
> the current C++ support in KDevelop. If possible, any help or at least hints
> on how to solve them would be much appreciated:
>
> 1) https://bugs.kde.org/show_bug.cgi?id=217180
> David - is this even possible? Can you elaborate on why this is not working as
> it should? Is each file parsed by itself and only macros get passed through? I
> ask because I started to use Eigen myself at university and it's an awesome
> tool but it's rather unusable in KDevelop right now.

Yes, each file is parsed separately. Also, the "preprocessing" step is
separate from the "parsing" step, which means that in the moment where
the #include is parsed, the namespace stuff is not known yet. If the
namespace context _was_ known, we could somehow pass it to the sub-job
(see sourceNeeded at preprocessjob.cpp:584). Maybe we could add some
ugly hack, to detect "namespace" prefixes without using the parser.
This is not nice though.

> 2) https://bugs.kde.org/show_bug.cgi?id=265686
> I dived into the code and what I found is only stripping of the qualified
> identifier of the current context. But:

This is done in stripPrefix(identifier, context), see cppduchain.cpp:642
It is basically done by shortening the prefix as long, as
findDeclarations(..) still finds the correct declaration.

The first thing you should do is creating a test with your example
code, and with a call to "stripType()" to make sure that it works
correctly. The actual problem might be, that stripType() requires a
DUContext, and maybe that one is not given to the call to
createArgumentList(), see the "ctx" variable in that function.

The "noShortening" paremeter only has the effect that the code stays
valid C++ (eg. without added ellipses).

Greetings, David