Two duchain bugs

[David Nolden]

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.

> 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, 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.

Greetings, David