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 _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
