Sent from my iPhone
On Mar 6, 2012, at 10:52 AM, jahanian <[email protected]> wrote: > > On Mar 5, 2012, at 8:10 PM, Douglas Gregor wrote: > >> >> On Mar 5, 2012, at 11:34 AM, Fariborz Jahanian wrote: >> >>> Author: fjahanian >>> Date: Mon Mar 5 13:34:00 2012 >>> New Revision: 152047 >>> >>> URL: http://llvm.org/viewvc/llvm-project?rev=152047&view=rev >>> Log: >>> patch to optionally warn for block implementations without explicit >>> return types that return non-void values. // rdar://10735698 >> >> This should not be a warning in Clang. It's an opt-in warning (which is a >> huge red flag) that is more about style than about finding real problems: >> someone got confused about the types of some C expressions (== returns an >> int in C, despite there being a _Bool in C99 and a BOOL in Objective-C) >> which resulted in a mismatch with the inferred return type of a block. The >> right solution to this problem is to improve the error message we produce >> when the mismatch occurs, e.g., by adding a note that points where the "-> >> return type" should be added, so the user knows exactly how to fix the >> problem. > > All right. I removed the patch in r152128. But, we do issue warning on other > occasions when certain coding style result in sometimes hard to detect bugs. > We issue warnings in objective-c all the time when many of them can be > regarded as coding style. One case (in c) which is well documented is: > when users are not pairing parenthesis when defining conditions; as in if > (i=1)… Isn't this a coding style? Those warnings find real bugs all the time. This warning doesn't detect bugs; it just subsets the language in a way that we don't want to encourage. - Doug > - Fariborz > >> >> - Doug > _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
