[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

[Douglas Gregor]

On Nov 11, 2008, at 3:24 PM, Argiris Kirtzidis wrote:
> 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.

Destructors aren't found by name lookup, so the IdentifierResolver  
never needs to see them. Same thing with conversion functions and  
constructors.

   - Doug