> On Oct 22, 2015, at 7:38 PM, Clark S. Cox III wrote:
>
> Add -Woverriding-method-mismatch:
But why is that (a) a warning not an error, (b) not enabled by default in Xcode
targets, and (c) not even deserving of a checkbox in the build settings?
Also, the name seems
> On 2015/10/23, at 9:09, Jens Alfke wrote:
>
>
>> On Oct 22, 2015, at 7:38 PM, Clark S. Cox III wrote:
>>
>> Add -Woverriding-method-mismatch:
>
> But why is that (a) a warning not an error, (b) not enabled by default in
> Xcode targets, and (c)
Add -Woverriding-method-mismatch:
% cc -Woverriding-method-mismatch -Wall -framework Foundation returnTypeTest.m
returnTypeTest.m:23:1: warning: conflicting return type in declaration of
'name': 'NSString *' vs 'NSSet *' [-Woverriding-method-mismatch]
- (NSSet*) name {
> On Oct 20, 2015, at 6:31 PM, Rick Mann wrote:
>
> Ugh. Precisely the type of regression that should've been caught by an
> automated test. Assuming it's not something in your project, that is ;-)
I know! I added a note to that effect in the bug report, trying not to
Watch out: the compiler in Xcode 7.1b3 is not detecting mismatched Obj-C return
types, at least for methods that return objects. For example, the following
compiles with no warnings, even with all typical warning flags enabled:
@interface Foo : NSObject
- (NSString*) name;
@end
@implementation
Ugh. Precisely the type of regression that should've been caught by an
automated test. Assuming it's not something in your project, that is ;-)
> On Oct 20, 2015, at 18:21 , Jens Alfke wrote:
>
> Watch out: the compiler in Xcode 7.1b3 is not detecting mismatched Obj-C
>