ahatanak added a comment. In https://reviews.llvm.org/D30174#681843, @arphaman wrote:
> Yes, we do. Primarily for the following reason: even if some target may > return a struct in a register, another target isn't guaranteed to do the same > thing. It's better to always warn about this rather than accept some small > structs. Furthermore, the official documentation states that "For methods > that return anything other than an object, use NSInvocation." [1], so methods > that return records are completely prohibited by the docs. OK, I think you are right. It doesn't seem like a good idea to warn when compiling for one target and not warn when compiling for another target. If the official documentation says the method should return an object, why not prohibit all methods that don't return a pointer to an object (methods like returnsInt in the test case)? Doing so will also take care of methods that don't return struct but still return via sret (for example, I think some targets return vectors via sret). Also, the documentation says that methods passed to performSelectorInBackground and performSelectorOnMainThread should not have a significant return value. Does it mean that the methods can have any return type but the return value will be ignored (I noticed that those two methods return "void" unlike performSelector which returns "id")? Repository: rL LLVM https://reviews.llvm.org/D30174 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
