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