Clang warnings

The Clang developers provide us with warnings for good reason: to catch bugs. Yet, I only know a handful of developers who actively use warnings to aid their development workflow. What about you? Ever had a retain cycle because self was strongly captured in a block? Ever had a bug like if(myVar = 42) { ... } vs if(myVar == 42) { ... }? Guess what, there are warnings for that! Clang is our friend so let’s polish up on our friendship!

Warning Basics

Before we get started we need to have a look at some basics behind Clang warnings.

Warning Groups

According to one of the Clang developers there are four predefined groups of warnings:

Name Description
On-by-Default “These warnings are always on unless you explicitly disable them.”
-Wall “These are warnings that the developers have high confidence in both their value and a low false-positive rate.”
-Wextra “These are warnings that are believed to be valuable and sound (i.e., they aren’t buggy), but they may have high false-positive rates or common philosophical objections.”
-Weverything “Don’t use this on your code. It is intended strictly for Clang developers or for exploring what warnings exist.”

Activating warnings

Clang allows us to either activate groups of warnings (e.g., -Wall from the previous section) or single warnings (e.g., -Wconversion).

Suppressing warnings

Let’s say you have activated the -Wall warnings group but you want to deactivate a single warning that you deem irrelevant. Clang allows you to suppress warnings by adding the -Wno- prefix, e.g., -Wno-conversion will suppress the aforementioned -Wconversion warning.

You can also suppress warnings temporarily via preprocessor macros. The following code snippet will suppress the -Wconversion warning for a given code part.

#pragma clang diagnostic push
#pragma clang diagnostic ignored "-Wconversion"

<your code>

#pragma clang diagnostic pop

Warnings = Errors

I tend to treat errors as warnings because every unfixed warning is a potential source of bugs. There are two ways to tell Clang to treat errors as warnings:

  • -Werror will treat all warnings as errors. That can be a bit obstructive during development so you might want to limit it to your CI and release builds.

  • -Werror=<warning-name> will treat only the specified warning as error, e.g., -Werror=conversion to treat -Wconversion as error.

If you set -Werror for all warnings you can also opt out from some errors using -Wno-error=<warning-name> and treat them as regular warnings instead, e.g., -Wno-error=conversion will treat the -Wconversion warning as regular warning again.

Managing warnings

Using the aforementioned basics we can develop a simple yet effective setup to use warnings to our advantage.

Step 1: Fix all warnings

I assume that you have not touched any warning settings of your Xcode project yet. Therefore, your project should only have the default warnings enabled. Please make sure that your project compiles without any warning before we start.

Step 2: Activate -Wall

Now that your project compiles without warnings we can start increasing your warning level. Therefore, switch to your target’s build settings and set the value of Other Warning Flags to -Wall.

Step 3: Deactivate irrelevant warnings

Compile your project and check the build log. You will probably have a lot of new warnings popping up. Have a look at each of them and write down the ones you deem irrelevant. Then fix the ones you want to keep. When you are done switch back to your target’s build settings and add each warning you want to deactivate to your Other Warning Flags with the -Wno- prefix.

Step 4: Fine tune

Add -Wextra to your Other Warnings Flags and compile your project. You should see a lot of new warnings popping up. Go through them one by one and write down the ones that you deem useful. Head back to your build settings, remove -Wextra from Other Warnings Flags, and add your list of warnings. Then fix all the warnings.

There is also a great list of Clang warnings that you can use to fine tune your setup. Have a look and check if there is anything useful that you can add.

You might want to repeat step 4 from time to time to check if there are any new useful warnings that you might want to add.

Congratulations, you are all set up now! Have fun chasing Pokémons instead of bugs!.

Which Clang Warning Is Generating This Message?