ARC restriction errors even with -fno-objc-arc #15

schell · 2015-05-01T17:48:02Z

It seems I'm getting ARC restriction errors even when the files involved are being compiled with -fno-objc-arc. I'm guessing some other related files also need to be compiled with -fno-objc-arc.

schell · 2015-05-01T17:49:53Z

No - that doesn't seem to solve the problem.

ExoticObjects · 2015-05-05T05:31:21Z

Theses same issues came up for me after switching to Cocoapods 0.37. I'd previously been using 0.35.1 because of this bug. Apparently that bug is fixed, but cocoapods still doesn't play nicely with handlebars-objc. @Bertrand - any ideas?

ExoticObjects · 2015-05-05T15:36:43Z

I've created the simplest possible project with handlebars-objc and cocoapods 0.37.0 and it fails. So this is a legitimate problem.

See here. Hopefully someone will have some ideas...

guillaumealgis · 2015-05-05T15:37:48Z

This is because Cocoapods apply the -fno-objc-arc flag (and others) on a file by file basis in Xcode instead of setting a global compiler flag for the whole target.
As some objc files are generated while compiling (by yacc and lex) these cannot have the flags applied in Xcode beforehand.

A solution is to add the flags added by Cocoapods (eg -fno-objc-arc -w -Xanalyzer -analyzer-disable-checker -Xanalyzer deadcode) in "Other C Flags" for the whole handlebars-objc target.

Please note however that these will be removed after each pod install.

Bertrand · 2015-05-05T15:41:27Z

Hello,

sorry, I’m busy working on another project right now, but I will look into this as soon as I can.

— bertrand.

On 05 May 2015, at 17:36, Exotic Objects [email protected] wrote:

I've created the simplest possible project with handlebars-objc and cocoapods 0.37.0 and it fails. So this is a legitimate problem.

See here https://github.com/ExoticObjects/test_handlebars_w_cocoapods/tree/master. Hopefully someone will have some ideas...

—
Reply to this email directly or view it on GitHub #15 (comment).

ExoticObjects · 2015-05-05T16:06:20Z

@guillaume-algis - will pod update also remove them? Or just pod install?

Also, thanks for taking the time to make a screenshot :-)

ExoticObjects · 2015-05-05T16:15:44Z

Great fix, but as you said - temporary. pod update also clears these flags.

Still, it's nice to have a workaround until this is addressed. Thanks again.

schell · 2015-05-05T16:22:04Z

Yes, thank you for that work around, nice sleuthing. 👍

ExoticObjects · 2015-05-05T18:13:37Z

@guillaume-algis - do you think it would be possible to use a post_install script to re-add these flags after pod install runs?

Something like this.

It makes sense to me conceptually, but I'm not sure which files would need altering. After adding the flags you recommended, I don't see them in any of the xcconfig files...

guillaumealgis · 2015-05-05T19:00:30Z

They are added in the Pod-handlebars-objc.xcodeproj/project.pbxproj file. But it could be possible to add them in the xcconfig instead.
Anyway, this is a rather ugly fix IMO, I'd much prefer fixing the bug upstream in Cocoapods.

But until the bug is addressed in Cocoapods, yes it should probably work.

ExoticObjects · 2015-05-05T19:11:55Z

I don't have a Pod-handlebars-objc.xcodeproj file in my test project.

I just have a top level .xcodeproj and a Pods.xcodeproj, and neither of them have the -fno-objc-arc -w -Xanalyzer -analyzer-disable-checker -Xanalyzer deadcode flags in them. (I've set the flags in XCode)

Am I missing something?

Also, this bug (or issue) has existed in Cocoapods for a long time. I'm not holding my breath for them to address it. So a hacky script might be a good thing to have around...

ExoticObjects · 2015-05-05T19:19:43Z

Oops, they are there like you said. In Pods.xcodeproj - thanks.

guillaumealgis · 2015-05-05T19:50:05Z

Also, this bug (or issue) has existed in Cocoapods for a long time. I'm not holding my breath for them to address it. So a hacky script might be a good thing to have around...

That's the beauty of open source: you can fix it yourself and open a PR ;)

ExoticObjects · 2015-05-06T04:20:08Z

After looking into Cocoapods XCodeproj, I decided to write a cocoapods post_install hook to re-add these flags after pod install (or update) runs. I'd initially thought that it would need to be a real hackjob, but the XCodeproj library is sensible and powerful. So this seems like (maybe) a semi-legit way to deal with the problem? I've tested it in two projects and it works.

Basically, it lets me run the latest version of Cocoapods (0.37.0) while using handlebars-objc. But it should be pretty good at setting any build settings that you might need to modify. Hopefully it will help someone out...

Here's the git repo for the script.

Danappelxx · 2015-10-06T02:52:18Z

So, how would I go about adding handlebars-objc as a dependency in my podpsec? The post-install hook works in a podfile, but I don't think you can add that in a podspec (at least, not in a third party one).

That said, props for having it work with Carthage :)

ExoticObjects · 2016-01-17T05:41:40Z

@Bertrand - will this ever be addressed on your side? Now that we are forced to use_frameworks! with cocoapods (necessary to use any swift pods), the fixes above no longer work.

guillaumealgis · 2016-01-17T11:51:41Z

@ExoticObjects we're using the following post_install hook with use_frameworks!, and it's working fine:

post_install do |installer|
    installer.pods_project.targets.each do |target|
        target.build_configurations.each do |config|

            # Fix an issue with this pod.
            # See https://github.com/Bertrand/handlebars-objc/issues/15
            if target.name == 'handlebars-objc'
                config.build_settings['OTHER_CFLAGS'] = '-fno-objc-arc -w -Xanalyzer -analyzer-disable-all-checks'
            end
        end
    end
end

ExoticObjects · 2016-01-18T18:16:45Z

Excellent! You saved me some time! Thanks.

EDIT: Well, I spoke too soon. After running your post_install hook, I'm getting the same errors as before.

I pushed a simple demo project to github that describes the problem.

Basically, using the simplest possible Podfile with the post install hook above will allow handlebars-objc to compile (hence my early enthusiasm...). But as soon as I attempt to use handlebars in any way, I get the same old errors.

NSString * str = [HBHandlebars renderTemplateString:@"" withContext:@"" error:nil];

results in:

ARC forbids Objective-C objects in struct

Hopefully I'm missing something simple!

schell · 2016-01-19T22:05:04Z

Is it a very large undertaking to update the code for ARC? Or are there other interests at play here?

Danappelxx · 2016-01-19T22:21:55Z

@ExoticObjects comment out the line that is throwing the error. Not a perfect solution (by any means) but it works.

ExoticObjects · 2016-01-20T01:15:49Z

I submitted a pull request. @Bertrand, please have a look! I can't think of any reason that this tiny change would break anything, but...

guillaumealgis · 2016-01-20T10:14:07Z

@ExoticObjects Just use #import "HBHandlebars.h" instead of #import <HBHandlebars/HBHandlebars.h>.

Also, your example project overrides the OTHER_CFLAGS setting at the target level. Delete all the occurrences of OTHER_CFLAGS = ""; in your pbxproj.

(Cocoapods complain about this after a pod install btw: )

[!] The `MainTarget [Debug]` target overrides the `OTHER_CFLAGS` build setting defined in `Pods/Target Support Files/Pods/Pods.debug.xcconfig'. This can lead to problems with the CocoaPods installation
    - Use the `$(inherited)` flag, or
    - Remove the build settings from the target.

[!] The `MainTarget [Release]` target overrides the `OTHER_CFLAGS` build setting defined in `Pods/Target Support Files/Pods/Pods.release.xcconfig'. This can lead to problems with the CocoaPods installation
    - Use the `$(inherited)` flag, or
    - Remove the build settings from the target.

Bertrand · 2016-01-20T11:11:11Z

@schell ARC slightly slows down code when a lot of objects are created. It's totally fine to use it in an application, but since in objc we have a choice, it's better to not use it in libraries. In swift of course it's a different story :)

guillaumealgis · 2016-01-20T11:38:36Z

it's better to not use [ARC] in libraries

I respectfully disagree. Not using ARC today is a major downside for 99.99% of the libraries (only exceptions are maybe performance-critical libs and, let's be honest, handlebars-objc isn't one of them).

ARC "performance downside" (if this is even a thing) is largely compensated by what it brings to the table.

Let me also use this as an occasion to remind you that I had a PR (#12) opened for more than a year to fix multiple memory leaks in this lib. Leaks which would have never existed with ARC enabled.

Bertrand · 2016-01-20T13:21:02Z

@guillaume-algis In my experience, on (big) real-life projects, moving to ARC incurrs at least 20% performance loss scattered all over the code and thus very hard to fix (due mostly to additional retain-release + atomic RC by default).

Performance loss may be fine for some apps (I generally use ARC for apps), but as a library, handlebars-objc cannot make that choice on behalf of developers.

GRMustache made the same choice, for exactly the same reason.

"handlebars-objc is not performance critical"
??????
I used handlebars-objc for batch-generation of text file, and had to optimise the lib quite a bit (in particular string generation) to get this fast.

Regarding the leaks, I'm sorry for that. I was away from all this this last year. I'm looking at your PR asap.

ExoticObjects · 2016-01-20T13:22:59Z

I'm glad your lib has the performance that it does!
On Wed, Jan 20, 2016 at 8:21 AM Bertrand Guiheneuf [email protected]
wrote:

@guillaume-algis https://github.com/guillaume-algis In my experience,
on (big) real-life projects, moving to ARC incurrs at least 20% performance
loss scattered all over the code and thus very hard to fix (due mostly to
additional retain-release + atomic RC by default).

Performance loss may be fine for some apps (I generally use ARC for apps),
but as a library, handlebars-objc cannot make that choice on behalf of
developers.

GRMustache made the same choice, for exactly the same reason.

"handlebars-objc is not performance critical"
??????
I used handlebars-objc for batch-generation of text file, and had to
optimise the lib quite a bit (in particular string generation) to get this
fast.

Regarding the leaks, I'm sorry for that. I was away from all this this
last year. I'm looking at your PR asap.

—
Reply to this email directly or view it on GitHub
#15 (comment)
.

Bertrand · 2016-01-20T14:09:19Z

Hmm, did not mean to close this one.

Bertrand · 2016-01-20T15:25:03Z

I just released v1.4.3, still based on Handlebars 2.0 but which should fix the issue.
Thanks to everyone who helped tracking down the issue.

Bertrand · 2016-01-21T09:35:00Z

@ExoticObjects is the issue solved on your side with the new pod version?

ExoticObjects · 2016-01-21T18:54:26Z

Yes, thanks!

guillaumealgis mentioned this issue May 5, 2015

[PodTargetInstaller] Dont set clang-specific flags for files that wont b... CocoaPods/CocoaPods#3460

Merged

ExoticObjects mentioned this issue Jan 20, 2016

Fix 'ARC forbids Objective-C objects in struct` error in HBAstNumber.h #16

Closed

Bertrand closed this as completed in 66e928a Jan 20, 2016

Bertrand reopened this Jan 20, 2016

Bertrand closed this as completed Jan 20, 2016

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

ARC restriction errors even with -fno-objc-arc #15

ARC restriction errors even with -fno-objc-arc #15

schell commented May 1, 2015

schell commented May 1, 2015

ExoticObjects commented May 5, 2015

ExoticObjects commented May 5, 2015

guillaumealgis commented May 5, 2015

Bertrand commented May 5, 2015

ExoticObjects commented May 5, 2015

ExoticObjects commented May 5, 2015

schell commented May 5, 2015

ExoticObjects commented May 5, 2015

guillaumealgis commented May 5, 2015

ExoticObjects commented May 5, 2015

ExoticObjects commented May 5, 2015

guillaumealgis commented May 5, 2015

ExoticObjects commented May 6, 2015

Danappelxx commented Oct 6, 2015

ExoticObjects commented Jan 17, 2016

guillaumealgis commented Jan 17, 2016

ExoticObjects commented Jan 18, 2016

schell commented Jan 19, 2016

Danappelxx commented Jan 19, 2016

ExoticObjects commented Jan 20, 2016

guillaumealgis commented Jan 20, 2016

Bertrand commented Jan 20, 2016

guillaumealgis commented Jan 20, 2016

Bertrand commented Jan 20, 2016

ExoticObjects commented Jan 20, 2016

Bertrand commented Jan 20, 2016

Bertrand commented Jan 20, 2016

Bertrand commented Jan 21, 2016

ExoticObjects commented Jan 21, 2016

ARC restriction errors even with -fno-objc-arc #15

ARC restriction errors even with -fno-objc-arc #15

Comments

schell commented May 1, 2015

schell commented May 1, 2015

ExoticObjects commented May 5, 2015

ExoticObjects commented May 5, 2015

guillaumealgis commented May 5, 2015

Bertrand commented May 5, 2015

ExoticObjects commented May 5, 2015

ExoticObjects commented May 5, 2015

schell commented May 5, 2015

ExoticObjects commented May 5, 2015

guillaumealgis commented May 5, 2015

ExoticObjects commented May 5, 2015

ExoticObjects commented May 5, 2015

guillaumealgis commented May 5, 2015

ExoticObjects commented May 6, 2015

Danappelxx commented Oct 6, 2015

ExoticObjects commented Jan 17, 2016

guillaumealgis commented Jan 17, 2016

ExoticObjects commented Jan 18, 2016

schell commented Jan 19, 2016

Danappelxx commented Jan 19, 2016

ExoticObjects commented Jan 20, 2016

guillaumealgis commented Jan 20, 2016

Bertrand commented Jan 20, 2016

guillaumealgis commented Jan 20, 2016

Bertrand commented Jan 20, 2016

ExoticObjects commented Jan 20, 2016

Bertrand commented Jan 20, 2016

Bertrand commented Jan 20, 2016

Bertrand commented Jan 21, 2016

ExoticObjects commented Jan 21, 2016