DUChain support of defaulted/deleted functions again

[David Nolden]

2011/6/20 Milian Wolff <mail at milianw.de>:
> 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.

The efficiency problem would only arise if we would start creating all
implicity-created functions. Since we don't create those functions, we
cannot even report when the user uses for example a non-existing
operator, and in this light, it doesn't seem very useful to report the
use of explicity-deleted operators.

Anyway, it shouldn't hurt, since this should not create any
false-positive error-reports.