[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.
-Argiris
More information about the cfe-commits
mailing list