[cfe-commits] r58866 - in /cfe/trunk: include/clang/AST/DeclBase.h include/clang/Basic/DiagnosticKinds.def lib/Parse/ParseDecl.cpp lib/Sema/SemaDecl.cpp test/SemaCXX/destructor.cpp

[Argiris Kirtzidis]

Chris Lattner wrote:
>
>> +++ cfe/trunk/include/clang/AST/DeclBase.h Fri Nov  7 16:02:30 2008
>> @@ -310,6 +310,10 @@
>>     }
>>   }
>>
>> +  bool isCXXRecord() const {
>> +    return DeclKind == Decl::CXXRecord;
>> +  }
>> +
>
> Why do you need this?  Why not just use isa<CXXRecordDecl>(D)?

DC.isCXXRecord() is prettier :-)

And another minor point is that isa<> on a DeclContext will incur an 
out-of-line function call.


Douglas Gregor wrote:
>
> On Nov 11, 2008, at 1:20 AM, Chris Lattner wrote:
>
>> Stepping back one level, is cramming a ~ into an identifier really the
>> right way to go here?  Maybe we should use a smart pointer of some
>> kind instead of relying on IdentifierInfo*?  We will eventually need
>> something richer like this to handle template-id's, right?
>
>
> The benefit to cramming the '~' into the identifier is that, once 
> we've done it, we get the right name for the destructor throughout the 
> compiler because its identifier is a human-readable name. We're 
> currently doing the same kind of hack with conversion functions, e.g., 
> "operator int const *", where we paste "operator" and then the type 
> name to create the identifier for the declarator.
>
> One possible fix would be to give the the Declarator a dummy name 
> (e.g., "<destructor>", "<conversion function">) or make use of the 
> flags that say that this isn't a normal named declarator, then make 
> NamedDecl::getName() virtual and override it for destructors, 
> conversion operators, etc., to form the name on-demand. Since 
> getName() isn't invoked unless we're emitting a 
> diagnostic---definitely not in the hot path---it's probably a good 
> tradeoff. We'll have to be a little careful throughough, since 
> getIdentifier() and getName() will have different strings associated 
> with them.
>

Another benefit of using different IdentifierInfos for "~C" and "C" is 
that the unique IdentifierInfo for the destructor allows it to be cached 
by the IdentifierResolver.

-Argiris