Another update to iOS (this time to 6.1) means another update to Xcode (this time to 4.6). No doubt some bugs will be squashed while other new ones are introduced - but the most immediate change that I’ve noticed is that another new crop of warnings are being generated.
I have the “treat warnings as errors” flag set by default on the basis that I’d rather know about a potential problem before it becomes an actual one. That’s fine for my code, but using 3rd-party libraries means that I’m mixing in code that may not necessarily have used that approach.
Since starting to use Xcode 4.6, there’s a whole set of new warnings that have popped up in the project I’m currently working on - and that grates on my probably-overly-anally-retentive habits.
There are several options for clearing errors in 3rd-party libraries:
Fixing the errors. This will obviously get rid of the warnings, but comes with a problem. I’ve now effectively forked the code, which means I’ll have uncommitted changes sitting around in Git. That’s even more fingernails-down-blackboard to me than compiler warnings, so this isn’t an option.
Fork the 3rd-party library and fix the errors. That’s probably the right thing to do from an open-source perspective, especially if I then create a pull request to the library’s author. But it also means I’ll need to remember to switch the library back as and when the warnings get removed in the main project; and as a casual user of the library rather than a core contributor, I’m probably not best-placed to do this anyway.
Turn off “treat warnings as errors” altogether. Not an option, as this would hide future warnings of my own creation.
Selectively disable the warnings. This is usually my preferred option. If the code used to work, still compiles and doesn’t fall over, then I’m reasonably happy that the root cause lies with Xcode’s opinions rather something fundamentally nasty. I’m not alone in working with the errors as warnings setting, so it will proably only be a matter of time before the library is updated. So overall, this feels like a reasonable compromise.
Selectively-disabling the warnings is similar to disabling ARC on a per-file basis. In the target’s Build Settings tab, you can double-click the problem file and add
-w -Xanalyzer -analyzer-disable-checker as a compiler flag.
This will prevent the analyzer checking the file at all, which won’t trigger the warnings. As it’s handled as a compile-time issue, the change is applied at the Xcode level and won’t affect the Git status of the library files themselves.
The downside to this approach is that the file will be ignored. However, if you’re applying this to 3rd-party code that you’re not going to touch, this is probably not going to cause any issues in the short-term. Updating 3rd-party code is best done by forking the library onto your own repo anyway, in which case you should have ‘treat warnings as errors’ turned on as it’s now your own code.