DUChain support of defaulted/deleted functions again

[Milian Wolff]

On Monday 20 June 2011 19:19:03 David Nolden wrote:
> 2011/6/20 Milian Wolff <mail at milianw.de>:
> > 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.
> 
> We can detect raw errors, but KDevelop will probably never be able to
> detect the extremely fine-grained errors. First of all because of the
> approximations we're inherently doing, and secondly because we will
> never have the manpower to tune the language-support to _exactly_
> fulfil the C++ standard (just take a look at that specification ;-)
> 
> So we'll have to live with an approximation where we detect the
> simplest errors, but leave the complicated errors to the compiler. The
> good thing is that most errors are relatively simple, and that's why
> even a simple error-reporting is very useful.

I agree. Yet there are many simple errors we do not yet report. See below, imo 
this case is one of them.

> Regarding the deleted functions: The C++ support does not create any
> declarations and/or uses for all these implicit functions anyway, so
> tracking of "delete" seems only useful if it is possible to delete
> functions that were defined _explicitly_ at some point. Reporting
> errors here is nothing we can do in near future, because this would
> first need us to create declarations for all of the implicit functions
> that exist. This would also reduce efficiency once again, so it's
> questionable whether we should even try to do it.

We can do it, as I've shown in the c++0x branch which already reports errors 
there. The thing is: We *only* need to report an error, when we try to mark a 
use of the *explicitly deleted* function. No need to track implicit functions 
or anything. And right now the code in newUse is more or less:

if (decl && decl->isExplicitlyDeleted()) {
  // report error;
}

I doubt this is a considerable slowdown as in most cases the 
isExplicitlyDeleted will be false.

Once we put this into a Cpp-specific type, we will need an additional dynamic 
cast. Still, I doubt this is significant when compared to the overall runtime.

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/739f676a/attachment.sig>