I'm not sure when this started but it seems like Xcode is not giving me type mismatch warnings/errors like it used to. For example, I just discovered a bug in my code where I was assigning the result of a method that returns NSString * to an NSInteger. The method prototype is correctly defined but the compiler gave no warning. Here is the code:
+ (NSString *)countryDialPrefix;
NSInteger prefix = [CountryCodes countryDialPrefix];
Here are the warnings set for all languages:
This was in "Other Warning Flags" at the Project level:
-w -Xanalyzer -analyzer-disable-checker -Xanalyzer unix
So I removed the -w and that fixed it.
Related
After upgrading from XCode 10.0 to 11
I am getting the error 'name' is unavailable: not available on iOS
This is during Build for Swift 4.2 on XCode 11.0 and 11.1 , I can still build using XCode 10
This is happening in the code of one of the Objective C external libraries we have been using through Cocopods.
return [(NSNumber *)[table[state] objectForKey:[rule name]] unsignedIntegerValue];
I can work around the issue by renaming the variable name to ruleName , but I would rather not do this.
Why is Xcode objecting to a variable name of name? Is this an Xcode but or is it something I can fix in the build settings
Edit
The specific pod is NUI 0.5.5
In module NUIPShiftReduceGotoTable.m
- (NSUInteger)gotoForState:(NSUInteger)state rule:(NUIPRule *)rule
{
return [(NSNumber *)[table[state] objectForKey:[rule name]] unsignedIntegerValue];
}
Apple made a change that can break previously compiling code in Xcode 11.0/11.1. Previously the compiler would be fine with passing the 'name' message to an object that it didn't know the type of. This can happen for many reasons in the weakly typed Objective-C world.
Currently in Xcode 11.1 you can do.
id x = nil;
[x name];
And this will compile, no problem. But:
NSObject *x = nil
[x name];
won't compile due to the compiler identifying the most likely selector being the API_UNAVAILABLE one in NSLayoutAnchor.h (maybe).
If the compiler had more information it can map the correct selector. This might be as simple as including the header for whatever has name property in the .m file that is failing.
My guess is something like in NUIPShiftReduceGotoTable.m you add a line
#import"NUIPRule.h"
I'm getting this warning "#warning 64BIT: Check formatting arguments" when upgrading my iOS app to the 64-bit architecture using Apple's 64-Bit conversion script.
Here's the code:
NSString *string;
NSInteger min=1;
string=[NSString stringWithFormat:#"%ld minutes",(long)min];
min was an int, which I changed to NSInteger. I also then changed the format statement from %i to %ld and type casted min to long.
Warning appears right above the string= line. This warning is showing up everywhere I changed an int to an NSInteger.
IIRC, the 64-bit conversion process adds this wherever it detects a format string being used. There should be an actual line in the code that begins with #warning. The warning is simply put there to alert you to double-check to make sure your formatting arguments are correct; once you've done this, you should be able to delete the #warning line from your source code and the warning should go away.
I have an NSString category class (NSString+URLEncoding.h).
I am running into and unknown selector crash, because the string I am calling the category method has been optimized into an NSCFConstantString by iOS.
-[__NSCFConstantString URLEncodedString]: unrecognized selector sent to instance 0x290174
I learned of the NSCFConstantString vs. NSCFString optimizations in iOS 5 from:
http://www.cocoanetics.com/2012/03/beware-of-nsstring-optimizations/
Is anyone aware of how I can get the NSString category to include the Constant strings or even force the var to be an NSString/NSCFString and not an NSCFConstantString?
Cheers,
Z
-edit-
Linker flags -ObjC -all_load are both already implemented
NSString+URLEncoding.m is included in the targets compile sources
NSString+URLEncoding.m implements the URLEncodedString method.
Checked for zombies.
I am adding a sharing service to ShareKit 2.0
header:
#interface NSString (OAURLEncodingAdditions)
- (NSString *)URLEncodedString;
implementation:
#implementation NSString (OAURLEncodingAdditions)
- (NSString *)URLEncodedString
{
NSString *result = (NSString *)CFURLCreateStringByAddingPercentEscapes(kCFAllocatorDefault,
(CFStringRef)self,
NULL,
CFSTR("!*'();:#&=+$,/?%#[]"),
kCFStringEncodingUTF8);
[result autorelease];
return result;
}
There's an issue with the linker that can cause its dead-code stripping to completely omit any object files that only contain obj-c categories (or that are otherwise unreferenced). Theoretically passing the -ObjC flag to the linker should fix this, but that doesn't seem to always work. You can work around this issue by providing the -all_load linker flag, which will cause the linker to always link in all object files.
Note that you might have to set -all_load on the parent project if your category is part of a sub-project or library that you-re including somewhere.
Update: I believe -ObjC is reliable now and has been for years so you can stop using -all_load for this issue.
Just spent 30 minutes figuring out exactly the same issue. After fiddling with linker I found out that the category wasn't present in Compile Sources list in my target's Build Phases. Be sure to check it's there.
__NSCFConstantString is a subclass of NSString, so any categories on NSString apply to __NSCFConstantString too.
Either you're not linking in your category, or your category doesn't define a URLEncodedString method in its #implementation.
The WWDC 2013 lecture slides contain a section that in some cases the explicit bridging casts can be omitted. I wrote this in Xcode 5 (using 10.8 though, not 10.9), and the compiler complains I need a bridging cast. Am I just totally not understanding the concept?
#import <Foundation/Foundation.h>
CF_IMPLICIT_BRIDGING_ENABLED
CFStringRef MyCreateStringFromNothing();
CF_IMPLICIT_BRIDGING_DISABLED
void SomeFunction() {
// compiler requires bridging cast here...
NSString* x = MyCreateStringFromNothing();
}
The reason I ask is I wanted to write:
NSString* s = CFUUIDCreateString(NULL, uuid);
and thought that the new work on implicit bridging should simply enable me to write this. But this also needs a bridging cast.
This appears to be sort of black magic, but from my experiments functions with "Create" in them don't work with implicit bridging.
When I compiled this:
CF_IMPLICIT_BRIDGING_ENABLED
CFStringRef MyCreateStringFromNothing();
CFStringRef MyGetStringFromNothing();
CF_IMPLICIT_BRIDGING_DISABLED
void SomeFunction() {
NSString *const fails1 = MyCreateStringFromNothing();
NSString *const fails2 = CFStringCreateCopy(kCFAllocatorDefault, CFSTR("FOO"));
NSString *const works = MyGetStringFromNothing();
}
The first two fail but the third one "works."
Note that implicit bridging apparently STILL does NOT actually keep the compiler from warning you about converting CFStringRef to NSString *, it just stops requiring you to insert a __bridge as well.
You'll notice that in slide at WWDC2013 in session 404 at 50:30, he uses CFDictionaryGetValue(), which returns a "void *", so it's one of the few functions that won't raise a warning. Any of the CF functions that return an actual type (e.g. CFStringRef, or CFDictionary) are still going to throw warnings, so, meh.
Check the compiler settings on the project and/or target. If this is an older project, you might have a stray option there causing you to use an older compiler. (This tripped me up a few times when I moved to Xcode 5 and wanted to use the latest Obj-C newness.)
These days, I always choose "Default compiler" in my build options.
A project that runs fine on Xcode3, fails to compile on Xcode4 with this error:
file://localhost/users/Ishaq/Projects/game01/libs/cocos2d/CCLayer.m:
error: Semantic Issue: Sending 'ccColor4B' (aka 'struct _ccColor4B')
to parameter of incompatible type 'CIColor *'
the code that throws this error is below (from cocos2d-iphone CCLayer.m):
+ (id) layerWithColor:(ccColor4B)color
{
return [[[self alloc] initWithColor:color] autorelease];
}
Somehow Xcode thinks this code is calling - (id)initWithColor:(CIColor *)color; of CIImage (inside CIImage.h). How can I set Xcode's brain straight? ;-)
I've got the same problem. My resolution was to explicitly cast it proper type which helps the compiler to find the proper class. So the code looks like this:
return [[(CCColorLayer*)[self alloc] initWithColor:color] autorelease];
You could change self to the actual classname CCLayer which should point Xcode in the right direction.
The same thing happened for me when using the "LLVM GCC 4.2" compiler. Changing the compiler setting to "Apple LLVM Compiler 3.0" fixed it.