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.
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? 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. -Stephen On Jun 4, 2013, at 6:15 PM, John McCall <[email protected]> wrote: > On Jun 3, 2013, at 8:11 PM, Stephen Lin <[email protected]> wrote: >> Here's a freshly rebased pair of patches. >> <this-return1.patch><this-return2.patch> > > I don't understand why EmitConstructorCall needs to take a ReturnValueSlot or > return an RValue. There's one call site, and it passes an empty > ReturnValueSlot and ignores the result. This seems to just be cluttering the > API. > > Is there a reason why these patches are separated? (Did I ask for that for > some reason?) > > John. _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
