Ignore conversions to NULL in gcc too.

Ignore conversions to NULL in gcc too.

Do something similar to r129758 and disable conversion to NULL warnings in
gcc >= 4.5.0 as well. The -Wno-conversion-null option was added in that
version, and not passing it makes the build fail when -Werror is activated
(the default).

R=hbono@chromium.org, thakis@chromium.org
BUG=
TEST=Build with gcc >= 4.5.0 and -Werror.
Landed in r195440

[Nico, 2013-04-18 17:36:12]

Thanks!

I think our bots build with gcc 4.6 now, but they're not red. Do you know why
not?

[Raphael Kubo da Costa (rakuco), 2013-04-18 18:00:01]

On 2013/04/18 17:36:12, Nico wrote:
> Thanks!
> 
> I think our bots build with gcc 4.6 now, but they're not red. Do you know why
> not?

I performed some tests with different versions of GCC (4.5, 4.6, 4.7 and 4.8)
and it looks like it got smarter in 4.8: in previous versions, `unsigned u =
NULL' did trigger that warning, whereas `void func(unsigned u = NULL)' did not.

[Nico, 2013-04-18 18:20:04]

So this is only needed for gcc 4.8+? Can you change the conditional then?


On Thu, Apr 18, 2013 at 11:00 AM, <raphael.kubo.da.costa@intel.com> wrote:

> On 2013/04/18 17:36:12, Nico wrote:
>
>> Thanks!
>>
>
>  I think our bots build with gcc 4.6 now, but they're not red. Do you know
>> why
>> not?
>>
>
> I performed some tests with different versions of GCC (4.5, 4.6, 4.7 and
> 4.8)
> and it looks like it got smarter in 4.8: in previous versions, `unsigned u
> =
> NULL' did trigger that warning, whereas `void func(unsigned u = NULL)' did
> not.
>
>
https://codereview.chromium.**org/14195026/<https://codereview.chromium.org/1...
>

[Raphael Kubo da Costa (rakuco), 2013-04-18 18:29:43]

On 2013/04/18 18:20:04, Nico wrote:
> So this is only needed for gcc 4.8+? Can you change the conditional then?

I guess so, done.

[Nico, 2013-04-18 18:31:26]

lgtm

[Raphael Kubo da Costa (rakuco), 2013-04-18 20:55:26]

On 2013/04/18 18:31:26, Nico wrote:
> lgtm

After this lands, do I need to send another CL to bump the hunspell SVN revision
in DEPS?

[Nico, 2013-04-18 20:57:04]

On 2013/04/18 20:55:26, Raphael Kubo da Costa (rakuco) wrote:
> On 2013/04/18 18:31:26, Nico wrote:
> > lgtm
> 
> After this lands, do I need to send another CL to bump the hunspell SVN
revision
> in DEPS?

I think so.

I'm not sure if CQ works for changes to deps/, so if this hasn't landed by
tomorrow, ping me and I'll land this manually.

[Raphael Kubo da Costa (rakuco), 2013-04-19 08:22:37]

On 2013/04/18 20:57:04, Nico wrote:
> I'm not sure if CQ works for changes to deps/, so if this hasn't landed by
> tomorrow, ping me and I'll land this manually.

It looks like clicking the "Commit" checkbox does not trigger the CQ. Could you
please land this change?

[cmp_google, 2013-04-21 20:52:38]

On 2013/04/19 08:22:37, Raphael Kubo da Costa (rakuco) wrote:
> On 2013/04/18 20:57:04, Nico wrote:
> > I'm not sure if CQ works for changes to deps/, so if this hasn't landed by
> > tomorrow, ping me and I'll land this manually.
> 
> It looks like clicking the "Commit" checkbox does not trigger the CQ. Could
you
> please land this change?

I believe the lack of CQ here is because your (rakuco's) checkout isn't
configured with git-svn, and so the "Base URL" on this CL isn't set correctly. 
If it was set correctly, we may see exactly what you're trying to commit.  I
believe it is via SVN to /trunk/deps/third_party/hunspell.  May work, but I
would not be surprised if we don't currently support landing outside of
trunk/src.

[Nico, 2013-04-22 04:32:38]

Landed manually in r195440.