Warnings-as-errors in js/src/

Bug 609532 changed the way the JavaScript shell is built so that compile warnings are treated as errors.  We already had a zero-tolerance policy for compile warnings in js/src/, but they tend to creep in, especially on Windows, because most people develop on Mac or Linux.  Already at least one Windows build turned red because of a warning, and it was immediately fixed by the dev responsible. Previously that warning would have lasted for days or weeks until someone on Windows got sick enough of it to fix it.

I’d love to see the same thing done for the entire browser, but judging by the reams of compile warnings that go by when building the browser, this won’t happen any time soon.

Oh, and if you don’t know about make -s (a.k.a. make --silent or make --quiet), you should try it. It’s indispensible!

5 Responses to Warnings-as-errors in js/src/

  1. I wonder if we could start small(er) and turn on warnings-as-errors in some browser directories. I might be up for doing this, at least for code I’m passingly familiar with.

    • Nicholas Nethercote

      jlebar: definitely, that’s the only way to make progress in the browser IMO.

  2. We previously had warnings-as-errors on, but it wound up getting turned off because it was just too easy to break corner cases. If we go down this road again, then we’ll need to limit it to very specific things, I think, like “building on a well-supported CPU architecture” “targeting a well-supported platform” “building with a known-good compiler”.

  3. See https://bugzilla.mozilla.org/show_bug.cgi?id=557566#c31 . I’m pretty sure there was an even-older incarnation of that, since the build machinery has been around forever.