DUChain support of defaulted/deleted functions again

[Milian Wolff]

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

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/20110622/d3802052/attachment.sig>