In XCode (version 5.1.1 in my case), when you click Edit/Refactor/Convert to Objective-C ARC, what exactly is supposed to happen?
My goal here was to convert my old code to use ARC.
I basically set Objective-C Automatic Reference Counting to Yes, then I did the above to "refactor" my code. It failed and I ended up spending 5 hours commenting out anything with autorelease, retain, release etc... from my code.
When I finally got all that done, I was able to proceed with the Convert to Objective-C ARC operation, which ended up telling me that no changes to my code were necessary, which was true because I had done it all manually.
Is it supposed to do what I did manually, but automatically? Why didn't it?
By turning "Automatic Reference Counting" on manually you told the compiler that the project was already using ARC. Therefore, conversion did nothing - you told the compiler it was already converted.
Obviously all the non-ARC features you used were now errors and you had to fix them.
The normal method is that you do not change to Automatic Reference counting. The compiler will then check out your code, make sure that it can convert everything (it won't convert your code if the static analyser finds reference counting bugs, or when things are too complicated), you fix all the things that it refuses to convert, and once everything is Ok you convert everything.
And the answer to your question is "NO".
Related
I am trying to run some code from some time ago, after recompiling Lua for proper architecture, I am having some issues with the following line.
KillScript* script = (KillScript*)lua_tointeger(L, -1);
I am getting the following error on that line:
Cast of 'lua_integer' (aka'long') to 'KillScript' is disallowed with ARC.
Does anybody know why wouldn't this logic work?
Thanks!!
ARC -- automatic reference counting -- doesn't allow you to move between non-object reference types and object reference types. A lua_integeris a C scalar.
You can do some unsafe casting dance to keep ARC enabled, but I suspect you'll run into other issues.
If it is a standalone project, turn off ARC and try compiling. You'll likely run into other issues-- deprecation, etc... -- but at least you'll probably have relatively sane memory management behavior.
i have this problem for a while now. I have iPhone project which was built with non ARC. And now somehow i need to add another smaller project to it, but that project was built with ARC. I have tried to copy files one by one, but ass soon as i was done, i got lots of ARC errors and some with Security.framework... Can someone help me? Or give me some ideas how should i proceed?
I have tried this but it didnt solvet issius with ARC...
ARC is done at compile time. ARC-enabled source code files need to be compiled with ARC, non-ARC source files need to be compiled without. It is a s simple as that. ARC is nothing but syntactic sugar injected by the compiler.
I have had this problem with some third parties not entirely migrated to ARC. Just create a static library around these files.
You could also try to change the per-file compiler options (see this question: How to disable ARC for a single file in Xcode 5?), but I would recommend against it since it will just become a maintenance burden in the end.
And of course, if it is your source code and not some third party: Migrate it to ARC. It is worth it.
Basically, I have an IOS app that functioned without issue.
While following the instructions at http://docs.urbanairship.com/build/ios.html#ios-push-getting-started, I reached the "Register Your Device" section asking me to compile.
After attempting to build the code in xCode 5 I received the following error "#implementation UAPushSettingsAddTagViewController #synthesize of 'weak' property is only allowed in ARC or GC mode".
Note:ARC mode is not in use.
Search for "weak" in your project code and the libraries you include. Change it to a "assign"
Edit:
As #TaylorHalliday points out in his comment below, my answer was rather incomplete.
Changing weak properties to assign will get rid of compiler errors, but it will potentially cause memory management problems if you don't understand how to use manual reference counting.
Since you're using manual reference counting you will need to go through your code and make sure that you retain objects that you need to persist, and then release all owning references to objects when you are done with them. Explaining the details is beyond the scope of a forum post. I suggest you search on "About Memory Management" in the Xcode help system, and read the entire Advanced Memory Management Guide.
You should probably also run the Analyze tool on your project to look for possible memory management problems.
Better yet, convert your project to use ARC. It's much easier to avoid memory management problems when using ARC.
I got same error when I added these two files to my project. My project wasn't enabled for ARC. I had to remove these files first and then had to convert my project to ARC. Then adding these files caused no error.
I have a project that is already transitioned to ARC. Now I'm trying to include an existing file from the other project, which is not using ARC and I want it to be ARC-compliant too: release-retains, [super dealloc]s gone from this file, quick fixes, other stuff "Convert to Objective-C ARC..." does.
The problem is I can't use the Edit->Refactor->"Convert to Objective-C ARC..." tool for this. If I select only this file in "Select Targets to Convert" screen I'm getting "Cannot Convert to Objective-C ARC" message because of errors like: "#synthesize of 'weak' property is only allowed in ARC or GC mode". But they are already in ARC mode indeed! Also numerous warnings: "Method possibly missing a [super dealloc] call"
If I select all files except marked with -fno-objc-arc while converting, I get only errors about weak properties.
Of course I can build and delete the release-retains manually but why to walk if there is a bus (Conversion tool)... So can I auto-transition a separate file to ARC?
Update: I do not want ARC to be turned off for this file with -fno-objc-arc flag, I want ARC used in this file.
If you insist on making Xcode do the work, create a new Xcode project and deselect "Use ARC" when creating it. Add the files to convert, and convert the project to ARC. Take the modified files and import them into your other project.
It's probably simpler, however, to convert the file manually. This is not difficult, even for a large file or an entire project. Just lean on the compiler: build your app, walk through the errors and simply delete all retain/release calls and convert any NSAutoreleasePools to #autoreleasepool {}. You may also need to add __bridge casts if interacting with core foundation types.
It sounds like you'll have to convert this file to ARC manually, instead of relying on the automatic conversion tool. You'll need to go through the file and remove all of the release, retain etc. I've done this before, and while it takes a while, it's not too painful. Rely on the error messages from Xcode to guide you what needs to be fixed/removed in the code.
Here's a couple of links I found that may help. Also look at Apple's ARC docs and WWDC 2011 talks (referenced at the bottom of the second link).
Xcode ARC conversion tool issue
http://blog.mugunthkumar.com/articles/migrating-your-code-to-objective-c-arc/
I'm revisiting an an older project and converting to ARC, my first time through Xcode's conversion tool (Edit -> Refactor -> Convert to Objective-C ARC...), and I'm seeing a couple things that I'm not sure are real issues or red herrings somehow.
I get, as expected a big list of things that the tool finds that prevent it from completing, but:
Many (all?) instances of retain/release/autorelease appear to be flagged as errors e.g. "release is unavailable: not available in automatic reference counting mode". Am I really supposed to get rid of all these myself? I thought that's what the tool did.
In many of my classes, I'm seeing a bunch of errors that look like phantom parse/build errors that have nothing to do with ARC. E.g. in a simple class that apparently has no ARC-related issues, I'll get an "undeclared identifier" on some arbitrary method implementation, and then a bunch of "Parse error: expected }" at the end of the file, etc. These are not real-- the project builds fine, and I don't see any proximate cause or resolution for the errors.
There are "real" issues in the list as well (expected bridging issues that need to be explicitly clarified in code) but there are so many random errors of the above variety that it's hard to even find the signal in the noise. This seems wrong to me.
Am I misunderstanding what this tool is really doing? Apple's docs say this:
Xcode provides a tool that automates the mechanical parts of the ARC
conversion (such as removing retain and release calls) and helps you
to fix issues the migrator can’t handle automatically
Thanks.
The tool does not get rid of them for you, but simply adds retain/release code as need under the hood at the time of compile.
Those problems very well may go away when you get rid of old reference counting code.
EDIT: Further explanation:
In Xcode 4.2, in addition to syntax checking as you type, the new
Apple LLVM compiler makes it possible to offload the burden of manual
memory management to the compiler, introspecting your code to decide
when to release objects. Apple’s documentation describes ARC as
follows:
“Automatic Reference Counting (ARC) is a compiler-level feature that
simplifies the process of managing object lifetimes (memory
management) in Cocoa applications.”
In other words, ARC does not "strip" reference counting from your code, but rather does it on it's own under the hood. You no longer have to type release or retain or dealloc again. One thing the ARC needs to work is for it to do the reference counting entirely on it's own (with no user reference counting to "get in the way").
Took a long time to resolve, but both of these issues seemed to stem from some custom macros I was using. I had a macro for release-and-set-to-nil that I was using frequently, like this:
#define RELEASENIL(x) [(x) release]; \
(x) = nil;
I'm still not sure why, but for some reason, the ARC conversion tool didn't take this in stride, and choked on it, throwing the release warnings and the parse errors. (Some interaction with the preprocessor?) When I changed the macro to remove the release line, the conversion proceeded much more in line with my expectations.
And yes, it does of course remove the messages for you. (I'm answering my own question on the off chance that someone else ever has this issue.)