On Jun 4, 2013, at 6:26 PM, Stephen Lin <[email protected]> wrote: > I actually just did that to make it consistent with the > EmitVirtualDestructorCall signature because I assumed that was what it was > like originally. I can remove the argument and return void instead though.
Ah, I see. Yeah, that seems more like a flaw in EmitVirtualDestructorCall than anything else. No reason to make the APIs look more complicated than necessary, and I can't really imagine a world where the rest of IR-generation needs to know that a constructor has an aggregate return value! > Is there any point to EmitVirtualDestructorCall taking a ReturnValueSlot and > returning a return value? One of the two places EmitVirtualDestructorCall is > called is EmitCXXMemberCall, which passes it a ReturnValueSlot and has an > RValue; if there no valid use call for that ReturnValueSlot being non-empty > should I change EmitCXXMemberCall to assert that and return RValue::get(0) > instead, in that branch? Yes, that seems reasonable. > No real reason for separating the patches, just thought it would be easier to > review that way since they're basically disjoint and I had them as separate > commits locally anyway. I can submit them to svn as one patch. Well, they're serving the same purpose. Could you combine them with the changes I've requested and send that out? And then I'll just review that. John. _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
