[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 akyrtzi at gmail.com
Thu Nov 13 01:50:10 PST 2008

Chris Lattner wrote:
> On Nov 11, 2008, at 12:24 PM, Argiris Kirtzidis wrote:
>>> 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.
> I don't think that follows.  There is nothing that would prevent using 
> something like our "Selector" class (which handles similar [in spirit] 
> things for ObjC).  Selectors wrap identifier infos, are uniqued and 
> are pointer sized by-value objects.

It's not only about uniqueness, IdentifierInfo also has a place to store 
a Decl (FETokenInfo).

A class that wraps IdentifierInfo will work but it needs to be more 
complex than a simple "smart pointer"; 3 bits won't be enough for the 
'operator' stuff and it will also have to be able to store a Decl.


More information about the cfe-commits mailing list