Jul 12, 2018

Guys, I wanted to share some ideas on how to work with compiler warnings. In my opinion compiler warnings are very helpful most of the time. My impression is that you feel the same given the recent commits where you are fixing them. The only way to prevent warnings from slipping through is by using the -Werror switch. Else, they will keep coming back; especially if there are existing warnings that make it hard to spot new ones in the noise. There is a workflow to softly transition to using -Werror effectively: 1. enable -Werror switch 2. disable errors for warnings that already exist using -Wno-error=$WARNING, e.g. -Wno-error=reorder (this doesn't disable the warning; it just makes it a non-error) 3. Then, over time, remove the -Wno-error=$WARNING switches one by one and fix the warnings alongside. This is a bit trickier in projects where the build flags are not maintained in the same repo as the project itself but still doable I think. I'm aware that sometimes warnings can be false positives but it's possible to selectively disable them using #pragma statements alongside a comment that explains why a warning is being a false positive. Pragmas are supported by all relevant compilers. There is one drawback when using -Werror: in refactorings where the code is changed heavily it can take some additional effort to make it compile (e.g. unused variables, etc.). I think that this annoyance is far outweighed by the benefit of getting helpful feedback from the complier and by preventing warnings from slipping back into the code base. Last but not least, there's the possibility that some warnings are not emitted by all compilers and therefore someone might accidentally break the build. However, it's the whole point of CI to prevent that from happening. If one warning behaves very inconsistently across compilers then it can be made a no-error warning as described above. What do you guys think? 🙂