DUChain support of defaulted/deleted functions again

[Milian Wolff]

On Wednesday 22 June 2011 20:50:05 Milian Wolff wrote:
> On Monday 20 June 2011 23:43:02 Milian Wolff wrote:
> > 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.
> 
> *push*
> 
> David, could you please answer this? I want to merge c++0x into master
> again, and this is preventing me from doing so...

I've merged it now. If someone feels like commenting now, please do so :)

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/20110624/2b113a7e/attachment.sig>