[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
dgregor at apple.com
Tue Nov 11 14:43:19 PST 2008
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
>>> 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
More information about the cfe-commits