I am using a project without ARC. I am trying to install RestKit on to the project. I tried following instructions given in the following links:
https://github.com/RestKit/RestKit/blob/master/README.md
http://www.raywenderlich.com/13097/intro-to-restkit-tutorial
But I am getting following errors
The errors happen on following lines:
1. Unexpected # in the program:
NSArray *attributeNames = [userInfoValue isKindOfClass:[NSArray class]] ? userInfoValue : #[ userInfoValue ];
Is this a valid Obj C syntax first of all.
Array subscript is not an integer
NSAttributeDescription *attribute = [entity attributesByName][attributeName];
attributeName is a CFStringRef
Has any one faced these issues. Please inform me the fix.
This is do to the use of Objective-C literal subscript access to the attribute property.
What version of Xcode are you building against and with what base SDK? Under Xcode 4.5.2 with a base SDK of 6.0 it compiles without an issue.
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 facing a strange "Expected a type" Error in Xcode 9.4.1 while compiling this project, which was once started as an objective-c project.
The file I'm looking at is an .h file, in a lib in the project. Normally this error was related to any messed up parentheses, but I can't see anything, nor has the file been touched since years.
#import "DDXMLDocument.h"
#interface DDXMLDocument (MKPAdditions)
- (id)initWithReadIO:(xmlInputReadCallback)ioread closeIO:(xmlInputCloseCallback)ioclose context:(void*)ioctx options:(NSUInteger)mask error:(NSError **)error;
#end
Can anyone explain what this error means?
As it is getting more weird for me,
I found another error which actually comes behind the one described above at build time:
DDXMLDocument *document = [[DDXMLDocument alloc] initWithReadIO:readCallback
closeIO:closeCallback
context:(__bridge void *)(inputStream)
options:0
error:nil];
Complete error description:
Implicit conversion of a non-Objective-C pointer type 'int (*)(void *, char *, int)' to 'id' is disallowed with ARC
So I assume it has something to do with the MAC Upgrade and the latest compiler version now used.
import missing, that was becoming necessary, all other errors have been follow up failures. --> close
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.
I have used JSONKit library to parse dictionary and get JSON string. All is well and good with normal devices (iOS7). But when i run application in iOS 7-64 bit simulator it was crashed at below method:
- (NSString *)JSONString;
And the crash message shows on this line of JSONKit.m class
Tried to find out it but not able to sort out.
And i ended up with our native NSJSONSerialization class.
Did any one sort out this?
As far as I know there are more than one patch versions that tried to fix the 64 bit crash issue you mention here, e.g. JSONKit 64bit crash fix by heroims.
They all tried to fix that troublesome line for getting tagged pointers, "the very first thing that a pointer to an Objective-C object "points to" is a pointer to that objects class":
*((void **)objectPtr)
I wrote a simple code to emulate the crash,
NSDictionary *dic = #{#"hi":#(4)};
void *keys[2], *objects[2];
CFDictionaryGetKeysAndValues((CFDictionaryRef)dic, (const void **)keys, (const void **)objects);
void *objectPtr = objects[0];
void *another = *((void **)objectPtr);//Only works for 32 bit machine
NSLog(#"%#",[another description]);
My guess is that for 64bit compiler, apple changed the tagged pointer implementation for NSNumber, which causes the crash. Check the discussion for tagged pointers here stackoverflow.com/questions/5819387/why-is-nsnumber-immutable
If I change NSDictionary *dic = #{#"hi":#(4)}; to NSDictionary *dic = #{#"hi":#"hello"}; it won't crash.
The patch I mentioned here just used object_getClass, which seems to defeat the original purpose, "Why not just use object_getClass()?..." (the comments right above)
So like you said now I also end up using NSJSONSerialization class.
There is an patched version of JSONKit here that fixes the 64 bit issues among others.
I posted this question on the Apple IOS Developers' Forum, with a notable lack of response. I'm hoping the StackOverflow wizards can help...
I'm developing an iOS 8 app using Swift. In Xcode beta 5 the code below code worked, but gives me a linker error in beta 6 and beta 7:
var sqlStr = "SELECT count(*) as count FROM nouns WHERE bucket = ?;"
var rs = db.executeQuery(sqlStr, withArgumentsInArray: [0] as NSArray)
The linker error is:
Undefined symbols for architecture x86_64:
__TFSs26_forceBridgeFromObjectiveCU__FTPSs9AnyObject_MQ__Q_", referenced from:
__TFC8les_Mots13WordGenerator9getBucketfS0_FT_Si in WordGenerator.o
(getBucket is a method in the UIViewController WordGenerator. If I reduce the method to just these two lines, I get the same error, and if I comment these two lines out, the error goes away, so I know the problem is here.)
The db.executeQuery() is an FMDB method with this signature:
- (BOOL)executeUpdate:(NSString*)sql withArgumentsInArray:(NSArray *)arguments;
If I change the code to this, it works in all betas:
var sqlStr = "SELECT count(*) as count FROM nouns WHERE bucket = '\(whereClause)';"
var rs = db.executeQuery(sqlStr, withArgumentsInArray: nil)
From the linker error and my trials-and-efforts to debug this, it appears that the cast of [0], which is of type AnyObject to an NSArray, which is required, is failing. I'm using this example, but I'm seeing similar problems in other areas of the app, all where an AnyObject has to be cast to an NSArray or NSDictionary.
The original code above works just fine in Xcode beta 5, but not in subsequent betas. Clearly I'm not understanding something about the AnyObject to NSArray cast, but I'm darned if I know what, and it appears that betas 5 and 6 enforce something not previously enforced. I've tried every kind of explicit cast I can think of, with no success.
Any help will be GREATLY appreciated.
I changed the Build location and the code now compiles, links and runs. Previously the Build location was Custom/relative to workspace; I changed it to Unique.
I have no idea why this would change things, as I had deleted derived data and cleaned the build folder many times. But...it worked, so if anyone is having the same problems, give this a try.