On Thu, November 13, 2008 1:50 am, Argiris Kirtzidis wrote: > 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.
I suggest that we pause this conversion for a day or so. I'm working on Chris's suggestion of a Selector-like class for declaration names. Once I've made it work the way I think it should, I'll post the patch on cfe-dev with some explanation and we can pick up the discussion there. - Doug _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
