Jump to definition doesn't work with overloaded functions

[David Nolden]

Am Donnerstag, 1. März 2007 19:13:49 schrieb Kris Wong:
> > It would certainly nice if kdevelop used type information to find the
> > right overload so cases like
> >
> > void foobar( int i1, char* c1);
> > void foobar( bool b1, char* c2);
> >
> > would work when the code looks like
> >
> > foobar(getInt(),getChar());
> >
> > But Kris already told me that this would probably be too
>
> time-consuming.
>
> > Still this is something kdev4 should make possible.
>
> Just a few of my own comments.  This would change the job of evaluating
> one expression (foobar(...)) to evaluating any number of nested
> experssions.  It would have to handle all of the different experssion
> types, such as:
>
> Inline values:
> foobar("my string", 3);
>
> Simple types/enums/macros:
> int var;
> foobar(var, Qt::AscendingOrder, MYMACRO("my string"));
>
> Functions (which may or may not be overloaded):
> foobar(i18n(" my string ").stripWhiteSpace(), myObject.myFunction(3));
>
> Beyond that, it would have to handle:
>
> Inheritence:
> class A {
> };
> class B : public A {
> };
>
> void foobar(const A&);
>
> class B myB;
> foobar(myB);
>
> Casting:
> void foobar(const B&);
>
> foobar(dynamic_cast<B*>(myA));
>
> Implicit conversion:
> class A {
> };
> class B {
>    operator A();
> };
>
> void foobar(const A&);
>
> class B myB;
> foobar(myB);
>
> Implicit construction:
> void foobar(const QString&);
>
> Foobar("my string");
>
> And I'm sure there are some scenarios I have not thought of.  So you can
> see why this isn't handled currently, and properly evaluating all this
> could be a time consuming operation.  Although I would agree with
> Andreas, it would be awesome if kdev 4 could handle this.  Even Visual
> Studio does not handle this, it finds all possible matches and asks the
> user to pick the one they want (which is annoying).

I was planning all that stuff, and theoretically it would be possible, but it 
would involve quite a bit of work to make it good. Some more operators should 
be implemented so more expressions could be parsed successfully. 
The expressions for all parameters could be parsed using the already available 
algorithms, then some new matching-logic would have to be implemented that 
should model what types are compatible to what other(uint is compatible to 
int, Slave is compatible to Parent, "hello" is compatible to QString, etc.).

Since kdevelop-4 will have a completely new code-completion, I don't know 
whether it's worth all the work.

Maybe a very simple version could be implemented, that at least uses the 
argument-count and very simple argument-matching, but then again it might be 
confusing having even more stuff that sometimes works, and sometimes 
doesn't. :)

greetings, David