On May 2, 2013, at 7:55 PM, Stephen Lin <[email protected]> wrote: >> It would be reasonable to change ItaniumCXXABI's >> BuildConstructorSignature to call HasThisReturn instead of relying >> on overrides. > > I was actually just going to have arrangeCXXConstructorDeclaration > prepopulate ResTy based on HasThisReturn, since it's already > prepopulating 'this'... > > But (and I might be wrong, apologizes for my unfamiliarity with the > code) it actually doesn't seem that easy to convert > ConstructAttributeList to take a GlobalDecl with the appropriate > constructor/destructor type, since ConstructAttributeList is called by > EmitCall, which doesn't directly have the information either, and (I > believe) the parameter needs to be on the call site in case the > constructor is defined in a different TU? > > Is there anything wrong with just checking the return type instead as > I did in my revised patch? It's some coupling since it assumes the > semantics of a constructor/destructor return value based on its type, > but it seems to be a very justifiable assumption even for any future > C++ ABI, and the assumption is documented.
Ah, I'm forgetting which functions are used from where. I actually intentionally *don't* want this to be picked up in the same way when constructing a call. For example, virtual calls to destructors cannot be marked with this attribute because none of these ABIs put this-adjustment thunks in the v-table. So it's quite important that we only add this attribute on a call-site when directly calling a function. That's also part of why I'm quite antsy about relying on the formal type of the ctor/dtor. The guarantee isn't necessarily there just because the type is set up that way. I'm not sure there's a compelling reason for EmitCall to get a Decl* instead of a GlobalDecl. John. _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
