4

I believe that warnings should be treated as errors. If you start ignoring warnings you'll start missing "important" warnings among the "unimportant" ones. So my Continuous Integration system fails a build if there are warnings.

One of my compilers has a bug that causes it to raise a warning when it shouldn't. My code is valid and compiles correctly, and I can't disable this particular warning.

How should my CI system handle this? Should I temporarily disable "warnings as errors", until the compiler is patched?

6
  • 10
    Does your compiler have a "suppress warnings" feature that you can apply at a specific point in the code? (such as the @SuppressWarnings annotation in Java). Using that only at the affected place would probably be the preferred solution. Otherwise you might easily miss out legitimate warnings. May 2 '13 at 13:26
  • 3
    Can you pass the compiler output through another program that would filter out that specific error? That is, write a wrapper for the compiler that processes the output (to make most build scrips happy that don't like build statements such as gcc foo.c | squasherror.pl)
    – user40980
    May 2 '13 at 14:05
  • @JoachimSauer No, I cannot disable the warning.
    – M. Dudley
    May 2 '13 at 14:17
  • @MichaelT That's a creative idea, I think you should turn your comment into an answer.
    – M. Dudley
    May 2 '13 at 14:18
  • Out of interest, what compiler are you using? I use Visual Studio and would have an awful time if I treated warnings as errors!
    – PeteH
    May 2 '13 at 19:35
10

When the compiler 'misbehaves' one could wrap it just as any other misbehaving application.

Depending on the build script and how it works, this can be done in one of two ways.

The ideal way, however, is to address the in the code rather than the compiler (thus the 0th way). If it is possible, this should be investigated first as it minimizes differences in build environments which can make it difficult to do a build on a different system.

Way 0 - ignore it from the compiler

This option should certainly be considered because while it makes the code slightly messier, it keeps the number of 'moving parts' in the build process lower, and thus less likely to have errors.

This has the significant advantage of that it keeps the build environment the same (compared to way 2). One wouldn't want to go and create a new Jenkins server and then have a bit of WTF time spent trying to figure out why it breaks the build to discover on the old build server, the compiler had a wrapper that the new one doesn't.

This is compiler and language dependant. MadKeithV mentioned the approach for Visual C++.

The SO question Selectively disable GCC warnings for only part of a translation unit? goes into it a bit for gcc which can be "summarized" as:

#pragma GCC diagnostic error "-Wuninitialized"
    foo(a);         /* error is given for this one */
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wuninitialized"
    foo(b);         /* no diagnostic for this one */
#pragma GCC diagnostic pop
    foo(c);         /* error is given for this one */
#pragma GCC diagnostic pop
    foo(d);         /* depends on command line options */

The docs for this can be seen in GCC 4.6 diagnostic pragmas

Clang uses a similar approach, though instead of GCC, its clang as specified in Ignore all warnings in a specific file using LLVM/Clang:

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

char b = 'df'; // no warning.

#pragma clang diagnostic pop

One can see that this could get very confusing if compiling the same source with gcc and clang...

In Java, one has the @SupressWarnings annotation.

Way 1 - filter through a pipe

gcc args file.c | supresswarning.pl

The supresswarning.pl script would then filter the output from gcc to identify if that specific error occurred and just take it out of the output. One could also pass in the file.c to the script and identify the line number where the annotation or macro occurs to avoid filtering real errors.

Note that this isn't quite as simple as it is shown - errors may come out on standard error rather than standard out, and the pipe would need to be adjusted appropriately. To maintain it that errors go out on the correct file handle, suppresswarning.pl would need to identify the errors and write them again to the proper file handle.

Way 2 - filter though a wrapper

If the build script doesn't like dealing with compilers in this way (think ant and maven style environments where it invokes the compiler itself), one could write a wrapper.

A wrapper for javac would call itself javac, invoke javac_real (the real javac that has been renamed), pass all of the options through to the real invocation and process the output and adjust return code and messages itself.

This can also be used the other way (to make it error out on warnings) if the compiler is returning warnings, and you want to fail on warnings, and the CI environment will do it if the compiler returns a non-zero exit code... but it isn't. The wrapper script could examine the output of the compiler and again, adjust the return code of the wrapper to be appropriate to the environment.

3
  • @Macke very good point. Way 3 is now Way 0 (we're programmers, we can deal with 0 based indexing...)
    – user40980
    May 2 '13 at 17:11
  • 2
    About 9 years ago, I wrote a small gcc wrapper to deal with just this kind of problem. Here it is. (Don't use the e-mail address on the web page; I don't often check it.) May 2 '13 at 17:49
  • Option 4: Change the source code so the error is not exposed. The build is broken, the normal way to fix a broken build is change the source code.
    – mattnz
    May 3 '13 at 3:28
4

For Visual C++ 2012 (and probably earlier) I use

#pragma warning(push)
#pragma warning(disable: XYZW)
  // Code causing spurious XYZW warning here.
#pragma warning(pop) 

It's not particularly pretty and sometimes you have to be rather broad in the scope of the warning, e.g. when inside a shared library, deriving from a template class that doesn't have an export statement, I haven't found any other way than disabling that warning for the whole file.

I only do this when the warning appears in the build logs, I've double-checked that it is spurious, and I have determined the absolute minimum amount of code necessary to disable the warning for so that it goes away. I do not disable the warning globally for the whole project.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.