[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