Two duchain bugs

[Bertjan Broeksema]

On Wednesday 30 September 2009 05:02:31 pm David Nolden wrote:
> Am Mittwoch 30 September 2009 16:35:18 schrieb Bertjan Broeksema:
> > Hi All,
> >
> > I've found two bugs in the (C++) use builder.
> >
> > 1) I build a AbstractType for "const std::string&" by using the
> > ExpressionParser. Next I look up the class declaration of QString,
> > iterate over its constructors and compare the type with the AbstractType
> > created by the ExpressionParser.
> >
> > pseudo code:
> >
> > ExpressionParser parser;
> > AbstractType::Ptr strType = parser.parse("const std::string&");
> >
> > foreach (FunctionDecl *ctor, qStringClassDecl->localUses("QString"))
> >   if (ctor->arguments().first->equal(strType())
> >      // The equal here is AbstractType::equal();
> >     do_my_stuff;
> >
> > Curiously this *does* work sometime but not all the time.
>
> You should find the exact types that this comparison fails for. And by
> using a debugger to step through the "equals" function, we would know the
> exact difference. There might be a difference in the types that is not
> visible in their string. Btw. you can alternatively try whether
> ctor->arguments().first->indexed() == strType()->indexed(). This should lead 
> to the same result though.

How can it be that a lookup of "const std::string&" results in a different type 
than the one used in the qstring header in the first place? The test case I 
have is this:

==== begin test file
#include <qstring.h> // Qt3 code
void test()
{
   std::string myStr("blah"); // std::string resolved via the qstring include.
   QString qs1 = QString(myString); // Explicit call so that a use is reported
}
==== end test file

Well I'll look into it when I've more time or when I really need the feature.

> > 2) Given the declaration of QString::QString(const std::string&), the
> > only uses reported are explicit calls to this ctor and not the implicit
> > ones.
> >
> > i.e.
> > std::string myStr("test");
> > QString s1 = QString(myStr); // Found!
> > QString s1(myStr);                // Not found!
>
> The second case has not been required for the refactoring done in KDevelop
> until now, so it has been not yet implemented / overlooked. The problem is
> that "QString s1(..)" is not an expression but just a simple declaration,
> and thus it is not handled be the ExpressionParser. Until now the
> expression- parser is executed on the contents of the paren only,

On the paren? Parent maybe?

> so it would require detecting such declarations a bit earlier in the use-
> builder and start the expression-parser on the whole function-call so the 
> use can be built.

Any change that you have a look at this at some point? Otherwise, could you 
provide more specific information about the use builder process needed in this 
context to eventually fix this.

Cheers,

Bertjan