I get: In file included from ../../../mozilla/gfx/angle/src/compiler/preprocessor/new/Tokenizer.cpp:1: ./Tokenizer.cpp:811:84: error: implicit conversion of NULL constant to 'bool' [-Werror,-Wnull-conversion] if ( ! ( yyg->yy_buffer_stack ? yyg->yy_buffer_stack[yyg->yy_buffer_stack_top] : __null) ) { ~ ^~~~~~ false That line of code is: if ( ! YY_CURRENT_BUFFER ) { which is defined on line 280 of the same file as: 280 #define YY_CURRENT_BUFFER ( yyg->yy_buffer_stack \ 281 ? yyg->yy_buffer_stack[yyg->yy_buffer_stack_top] \ 282 : NULL)

I have no idea why this started (pretty recently)... The -Werror has been there for a while, so clearly something else changed?

Looks like this started with bug 778980?

I tried updating clang to the revision our builders use (163716), but the problem remains. This is completely blocking work for me. :( I have no idea how this is compiling on the builders....

Oh, I'm on 10.8 in case that matters....

(In reply to Boris Zbarsky (:bz) from comment #3) > This is completely blocking work for me. :( Ouch. If you back out 778980 locally, does that fix it for you? Do that allow you to unblock your work?

Yes, as long as I remember to qpush/qpop it every time I pull. Which means I get full "hey, configure changed" rebuilds on each pull....

So, if you build without --enable-warnings-as-errors (or with --disable-warnings-as-errors) does it succeed? FWIW I've had to disable it myself from time to time, as I use a more recent GCC than the builders have.

> So, if you build without --enable-warnings-as-errors (or with --disable-warnings- > as-errors) does it succeed? No, it does not. Looks like this particular -Werror bit is not controlled by --disable-warnings-as-errors...

That is a very good basis to back out 778980.

Bug 778980 added gcc -Werror=conversion-null because, AFAIU, these NULL conversions were errors with clang, but only warnings with gcc. If that is not true, then backing out bug 778980 sounds like a good idea.

Meh, even if that is not true -- -Werror is only a good idea insofar as it's not too much of a PITA. A -Werror that can't be turned down by a --disable-warnings-as-errors is IMHO not OK.

Dunno. I certainly can't get clang to even warn on a simple testcase that tries to reproduce something like the code from comment 0 in a standalone .cpp file. And yet it definitely warns on the actual angle code, and does so non-fatally before bug 778980 afaict.

If I run a .i file from bz's machine through my clang (on a Linux system, r163985), I get the warning as well, for what it's worth.

I'm kinda curious. Does this also warn with clang on our builder setup?

I just checked, and I get the same build failure on my 10.6 machine, with XCode 3.2.6. So I _really_ don't understand how this is possibly building on our infra. :(

Different OS X SDK target?

OK, I talked to Chris about this and we're going to back out bug 778980, more or less.

Or more precisely just part 5 of it.

Comment on attachment 670251 [details] [diff] [review] Turn off -Werro since we trigger it with ANGLE on recent Macs. Review of attachment 670251 [details] [diff] [review]: ----------------------------------------------------------------- LGTM. Sorry for the build hassles! ::: configure.in @@ +1487,5 @@ > # -Wtype-limits - catches overflow bugs, few false positives > # -Wempty-body - catches bugs, e.g. "if (c); foo();", few false positives > + # -Werror=conversion-null - would catch conversions between NULL and > + # non-pointer types, but unfortunately ANGLE > + # triggers it on Mac. I think we should just remove any mention of -W[error=]conversion-null. You can leave the comment if you think it will prevent someone from breaking ANGLE in the future, but configure.in is already a very large file without documenting things we're _not_ doing. :)