In addition to the well-known -Wall
, clang offers another interesting warning flag: -Weverything
. While it sounds like a “strictly better” option (the more warnings, the better?) it’s not.
This topic is already well covered by Arthur O’Dwyer’s blog post and the clang documentation.
Arthur makes a strong case against use of this flag. The clang docs generally agree, though offering a slightly more lenient position:
If you do use
-Weverything
then we advise that you address all new compiler diagnostics as they get added to Clang, either by fixing everything they find or explicitly disabling that diagnostic with its corresponding Wno- option.
But what I have not seen clearly expressed is how use of -Weverything
is a tradeoff.
The downsides are:
- Increased flag noise from having manually resolve contradicting flags (using
-Wno-c++98-compat
and-Wno-missing-prototypes
) - Friction in upgrading compilers. Upgrading may “break” your existing warning-clean code, because of new warnings that have been added. This means you need to resolve all of those issues (via fixing code, or adding new flags to disable warnings) before officially supporting the toolchain.
- Exposure to “experimental” diagnostics that may be “lower quality”.
However, there are advantages:
- Discovering useful new warnings that you may never have used otherwise
- Finding and fixing bugs during compiler upgrades as a result of these new warnings
Whether you are working on a library or application will also affect your decision.
If you maintain a library (especially an open source one), it makes sense to avoid -Weverything
. You have less control over which compiler versions your users use, and you want to avoid users encountering new warnings if they use a new compiler release to build the library. (Assuming you keep a warning-clean codebase).
However, if you are simply developing an application (especially a closed source one), it may make sense to use -Weverything
. In this environment, you have complete control over the approved toolchain that can be used to build the project, and can have a transition period where new warnings are addressed. There will be more friction for toolchain upgrades, but you may find that the benefits in continually using the newest warnings outweigh that downside.
Thanks to Ryan Brown for teaching me about this.