'Treat warnings as errors' is the greatest thing since shirt pockets. I've found that most warnings are really latent errors. I've been using this setting for as long as I've been compiling with GCC/LLVM, going back to gcc 2.x.<p>Whenever I take over a new project I immediately endeavor to fix all the warnings. The reason is simple: I've spent too much time chasing bugs that were directly related to a specific warning in a sea of them. Once you get a project warning-free it's quite easy to keep it that way.<p>Regarding the author's specific complaint--unused variables--I find that it's quite simple to comment out the declaration. There's no need to resort to pragmas in this instance.
I find it horrifying how many developers are perfectly happy having warnings in their code.<p>On the projects I manage, warnings are unacceptable, and treated as errors. We will not release an update until it builds without warnings.
This post has made me visit one of my large project's warnings. There are two that I can't seem to be rid of:<p>Using NS_REQUIRES_NIL_TERMINATION on a var args Objective-C method seems to cause a warning "Attributes on method implementation and its declaration must match" — despite both the declaration and implementation being exactly the same.<p>Using uniqueIdentifier in debug builds (for TestFlight) triggers an API deprecation warning. Despite being OK to use for non-App Store iOS apps.
The author just retweeted a link to this header file to enable Clang warnings using #pragma's <a href="https://github.com/macmade/SeriousCode" rel="nofollow">https://github.com/macmade/SeriousCode</a> <a href="https://twitter.com/macmade/status/328219581879558144" rel="nofollow">https://twitter.com/macmade/status/328219581879558144</a>
I find apples compiler seems to change its mind on what is a warning with every single version, which in turn made me less interest in removing every single one of them (especially when you use third party stuff - unity3d seems to spit out a bunch of warnings right now).
I never do -Wall and -Wextra. Why? Because too many of clang's warning switches have names that have little to do with what they actually warn about. One in particular has to do with it finding duplicate selectors in different classes. I can never remember what it's called, but it's very annoying when you need to find it to disable it. Even worse, when you disable that particular flag, it disables a whole bunch of other actually useful warnings as well!<p>You also DON'T want to do -Wall and -Wextra along with -Werror. Why? Because when a later version of the compiler gets smarter and puts in more warnings, suddenly your (working) code won't compile anymore! That would go over very poorly in a CI system or an open source library! Your "future proofing" has just ensured that sometime down the road (and likely at an inconvenient time), your project is guaranteed to break!