-Werror Is not your friend (2017)

A previous company I worked at had large C++ projects that built with 5000+ warnings. Nobody looked at them, obviously. Buried within them I recall one about printf-style formatting string mismatching arguments, that said something like “mismatching arguments will cause a crash if this code is executed.” I only noticed it buried in the list of warnings after debugging a segfault caused by that line of code.

Similarly, let’s say we’re talking about an open source project that users may download and compile from source. A portable open source project shouldn’t needlessly break if you use a newer or different compiler.

So:

- Do make the source code as clean as you can, using all tools available, including -Werror. Putting -Werror in your continuous build should be fine too.

- When a user downloads your library and compiles it in order to use it, the make target (or equivalent) that they use shouldn’t compile with -Werror, because we don’t know which compiler they have or which warnings that enables.

I think it is the only sane way for C++.

https://github.com/ClickHouse/ClickHouse/

Changing toolchains is a very rare occurrence because the subtle differences will almost always cause problems. When someone suggests changing toolchains, they owe everyone a VERY CONVINCING argument. After which the changed warnings will be the LEAST of your problems as you migrate.

Toolchain upgrades will cause new warnings to surface as the detection gets better. But you DO want to fix them, don't you? You ARE a professional, aren't you? You DO care about your product's quality, don't you?

After over a decade without werror, followed by a decade with werror, I'd take werror every time. Warnings exist for a reason, and in the case of C compilers, VERY GOOD reasons that you really should address.

At my workplace, we use werror, static analysis, various lints, detekt... everything that can issue warnings about your code quality. If any of them complain, you can't merge your PR, because we're professionals.

The biggest and rather frustrating issue left is that warnings are heavily tool depended, not just in that new tools will produce new warnings, but in that different tools will produce incompatible warning. The workaround that makes the warning go away in one tool, will create a warning in the other. You can end up with a lengthy back&forth before you find something that makes all the tools happy and you frequently run into situation were you are really just pleasing the tools, not fixing any actual issues.

there’s so many ways to skin that cat.

Warnings spilling over from library dependencies can be mitigated easily by including them using -isystem instead of -I.

For code that is not libraries, there is nothing strange about having dependency on a specific toolchain, preferably two supported options.

Besides, warnings or not, devs using different toolchains than CI is just inviting for works-on-my-machine situations the rest of us left behind in the last century.

> This flag adds a toolchain dependency to your project. Newer compiler versions (or alternative compiler vendors) are likely to generate new warnings, making the build fail.

IMO most large projects will anyway have multiple toolchain dependencies. Ever tried to compile Chrome using a different compiler/build system? And why would different contributors use different toolchains anyway? If you want to contribute, just use the same tools everyone else on the project uses.

When upgrading compilers, incompatible warnings are going to be the least of your worries. So what is the problem that the author wants to solve by not using -Werror? He agrees that warnings should not be merged. So why not stop them right when they're written?

>>> We primarily use Clang, and it is a common occurrence that our CI server will report a warning when compiling our “warning-free” code with GCC.

... my only point here is: FIX YOUR TOOL CHAIN why do you want to use Clang if all your dependency relies on GCC?

Then use -Werror=<warning-name> for each such diagnostic.

The problem there is that GCC fails if you give it an option it doesn't recognize, including just a diagnostic one.

If you use -Werror=funky-new-warning, it will fail on an older GCC that doesn't have funky-new-warning.

But since my libraries don't ship with build system files those build process decisions are my own and don't "leak" to the users of my libraries (e.g. it wouldn't even enter my mind to dictate a specific build system or build settings on my library users, I know how bad it is to deal with overengineered cmake files of other people).

When integrating other libraries I usually also just throw away the 1000+ lines of cmake files they come with and replace them with a few dozen lines of cmake script of my own (I wish that would be an exaggeration or a joke, but it's not - especially when it comes to "professional" C++ libraries coming out of Khronos or Google).

When updating the toolchain you can set default flags to disable the new warnings if you wish to fix each warning one a time.

I prefer modern languages like Go, because all these warnings and errors are just part of the default "go build":

    package hello
    
    func world() int {
       println("world")
    } // hello.go:5:1: missing return

That’s pretty close to rustc.

And I get that you can’t throw that at a giant codebase in one day, and I get that dev builds probably drop —Werror. Thrrr are realities.

But new stuff not under clang-tidy, cppcheck, and pvs if you’re feeling speedy? People do that?

There's a good chance your old code will compile if you don't use -Werror, or even if you do, but whether it runs the way it used to is a different question entirely.