[cfe-commits] r152047 - in /cfe/trunk: include/clang/Basic/DiagnosticSemaKinds.td lib/Sema/SemaExpr.cpp test/Sema/block-missing-return-type-warning.c test/Sema/warn-unused-parameters.c

Douglas Gregor dgregor at apple.com
Tue Mar 6 11:08:03 PST 2012



Sent from my iPhone

On Mar 6, 2012, at 10:52 AM, jahanian <fjahanian at apple.com> 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
> 




More information about the cfe-commits mailing list