DUChain support of defaulted/deleted functions again

[Milian Wolff]

On Sunday 19 June 2011 23:18:33 Wolfgang Bangerth wrote:
> > Do we even need to track deleted declarations at all? Wouldn't it be
> > enough to simply not create them?
> 
> I don't know the current representation in KDevelop, but the point of
> =delete'ing a declaration is that the compiler would otherwise create it
> itself. Say, for example, a copy constructor -- the compiler would create
> it by itself if you don't do it yourself; strictly speaking, KDevelop
> would have to implicitly create this declaration for its internal
> representation as well, but omit this implicit declaration if the copy
> constructor is =delete'd.

Not only that but you can also delete unwanted implicit conversion overloads, 
see e.g. :

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2346.htm#conversions

For that we need a declaration that we find through the usual lookup and only 
then we can say whether it was deleted explicitly or not.

> That said, I'm not sure whether it is useful to track this information.
> After all, if I have something like this:
>   struct X {};
>   void f() {
>     X x;
>     x.foo();
>   }
> then KDevelop happily lets me use this member function foo() even though it
> doesn't exist.

If you enable "highlight semantic problems" in configure -> language support, 
the use of foo() will be squiggly-underlined in yellow and you'll see the 
error message on hover or in the problems toolview.

> Tracking whether a special function is deleted only makes
> sense if KDevelop were going to take action if a user was going to use
> this function and remind her that that is an error -- but I tend to think
> that this would be better left to the compiler.

I disagree wholeheartedly: One of the big advantages of KDevelop for me and 
lots of other users I've spoken with on conventions and at work, is that it 
reduces the number of required compile cycles. If we can spot the error via 
our semantic analysis, we can report it ASAP and make the "compile -> darn, 
error -> fix -> recompile" superfluous.

> (Or is the standard way of
> reporting such errors in the "Problems" tool view, which indeed shows me
> that foo doesn't exist?)

See above.

Bye
-- 
Milian Wolff
mail at milianw.de
http://milianw.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20110620/f5d4521c/attachment.sig>