Turn on -Wmissing-field-initializers on Linux.

Turn on -Wmissing-field-initializers on Linux.

Because not initializing fields can be, you know, dangerous.

Committed: https://crrev.com/148e7076cafcbe35440c5acb9880695de9d5e5b1
Cr-Commit-Position: refs/heads/master@{#36071}

[Jakob Kummerow, 2016-05-04 16:48:12]

jkummerow@chromium.org changed reviewers:
+ bmeurer@chromium.org, titzer@chromium.org

[Jakob Kummerow, 2016-05-04 16:48:12]

Ben, please look at wasm files.

Benedikt, please look at non-wasm files.

Michael, FYI. I hope this doesn't make any bots angry. Our default clang likes
it.

In a bunch of places in the tests the write barrier flag's value doesn't seem to
matter. I've picked kFullWriteBarrier where it looked like generic tagged values
were used. We can also use kNoWriteBarrier everywhere which is what the previous
implicit behavior would have been.

I'd suggest to turn on the warning on other platforms after we know Linux builds
are happy with it.

https://codereview.chromium.org/1952703002/diff/1/gypfiles/standalone.gypi
File gypfiles/standalone.gypi (right):

https://codereview.chromium.org/1952703002/diff/1/gypfiles/standalone.gypi#ne...
gypfiles/standalone.gypi:713: '-Wmissing-field-initializers',
Omitting this entirely appears to *not* turn on the warning.

[Benedikt Meurer, 2016-05-04 17:34:43]

Awesome Jakob. Thanks for investing the time to make this less unsafe! LGTM.

[Michael Achenbach, 2016-05-04 19:29:27]

> Michael, FYI. I hope this doesn't make any bots angry. Our default clang likes
> it.

LGTM. If this is a clang-only warning, I could imagine gcc might warn about a
non-existing flag... But I guess it would have done that already for the old
flag...

[Michael Achenbach, 2016-05-04 19:33:00]

On 2016/05/04 19:29:27, Michael Achenbach wrote:
> > Michael, FYI. I hope this doesn't make any bots angry. Our default clang
likes
> > it.
> 
> LGTM. If this is a clang-only warning, I could imagine gcc might warn about a
> non-existing flag... But I guess it would have done that already for the old
> flag...

Hmm, or maybe it's the contrary. On our arm xbuilders I can see that warning
already. So I assume it'll go away with the fixes from this CL:
https://build.chromium.org/p/client.v8.ports/builders/V8%20Android%20Arm64%20...

[titzer, 2016-05-06 07:24:43]

On 2016/05/04 19:33:00, Michael Achenbach wrote:
> On 2016/05/04 19:29:27, Michael Achenbach wrote:
> > > Michael, FYI. I hope this doesn't make any bots angry. Our default clang
> likes
> > > it.
> > 
> > LGTM. If this is a clang-only warning, I could imagine gcc might warn about
a
> > non-existing flag... But I guess it would have done that already for the old
> > flag...
> 
> Hmm, or maybe it's the contrary. On our arm xbuilders I can see that warning
> already. So I assume it'll go away with the fixes from this CL:
>
https://build.chromium.org/p/client.v8.ports/builders/V8%20Android%20Arm64%20...

LGTM

[Jakob Kummerow, 2016-05-06 09:45:54]

The CQ bit was checked by jkummerow@chromium.org

[commit-bot: I haz the power, 2016-05-06 09:46:06]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1952703002/1
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1952703002/1

[commit-bot: I haz the power, 2016-05-06 10:20:09]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2016-05-06 10:20:35]

Description was changed from

==========
Turn on -Wmissing-field-initializers on Linux.

Because not initializing fields can be, you know, dangerous.
==========

to

==========
Turn on -Wmissing-field-initializers on Linux.

Because not initializing fields can be, you know, dangerous.

Committed: https://crrev.com/148e7076cafcbe35440c5acb9880695de9d5e5b1
Cr-Commit-Position: refs/heads/master@{#36071}
==========

[commit-bot: I haz the power, 2016-05-06 10:20:36]

Patchset 1 (id:??) landed as
https://crrev.com/148e7076cafcbe35440c5acb9880695de9d5e5b1
Cr-Commit-Position: refs/heads/master@{#36071}