Fix some clang warnings with -Wmissing-braces in base.

Fix some clang warnings with -Wmissing-braces in base.

Clang warns if there are missing braces around a subobject
initializer. The most common idiom that triggers this is:
  STRUCT s = {0};
if the first field of STRUCT is itself a struct. This can
be more simply written as:
  STRUCT s = {};
which also prevents the warning from firing.

BUG=505297
Committed: https://crrev.com/e74809cbb56e2ad906e0fbca6f97935242d3ed5f
Cr-Commit-Position: refs/heads/master@{#337139}

[dcheng, 2015-07-01 18:27:31]

dcheng@chromium.org changed reviewers:
+ thakis@chromium.org

[dcheng, 2015-07-01 18:27:34]

https://codereview.chromium.org/1218243002/diff/1/base/win/scoped_variant.cc
File base/win/scoped_variant.cc (right):

https://codereview.chromium.org/1218243002/diff/1/base/win/scoped_variant.cc#...
base/win/scoped_variant.cc:12: const VARIANT ScopedVariant::kEmptyVariant =
{{{VT_EMPTY}}};
FWIW, 100% of the votes felt kEmptyVariant = {} was clear enough?

Though the sample size is 2, and that depends on you knowing that VT_EMPTY == 0.

[Nico, 2015-07-01 18:36:51]

Note that `STRUCT s = {0};` only warns if the first element of s is itself a
struct. If it's a regular field, `= {0}` is fine.

[Nico, 2015-07-01 18:40:49]

lgtm

https://codereview.chromium.org/1218243002/diff/1/base/file_version_info_unit...
File base/file_version_info_unittest.cc (right):

https://codereview.chromium.org/1218243002/diff/1/base/file_version_info_unit...
base/file_version_info_unittest.cc:39: const wchar_t* kExpectedValues[1][15] =
{{
nit: const wchar_t* const

https://codereview.chromium.org/1218243002/diff/1/base/file_version_info_unit...
base/file_version_info_unittest.cc:58: for (int i = 0; i < arraysize(kDLLNames);
++i) {
nit: Since arraysize(kDLLNames) is 1, maybe get rid of this loop and make that a
scalar not an array?

https://codereview.chromium.org/1218243002/diff/1/base/third_party/nspr/prtim...
File base/third_party/nspr/prtime.cc (right):

https://codereview.chromium.org/1218243002/diff/1/base/third_party/nspr/prtim...
base/third_party/nspr/prtime.cc:110: SYSTEMTIME st = {};
This is a third-party file. Update base/third_party/README.chromium and upstream
this to nspr

[dcheng, 2015-07-01 21:26:39]

https://codereview.chromium.org/1218243002/diff/1/base/file_version_info_unit...
File base/file_version_info_unittest.cc (right):

https://codereview.chromium.org/1218243002/diff/1/base/file_version_info_unit...
base/file_version_info_unittest.cc:39: const wchar_t* kExpectedValues[1][15] =
{{
On 2015/07/01 at 18:40:48, Nico wrote:
> nit: const wchar_t* const

Done.

https://codereview.chromium.org/1218243002/diff/1/base/file_version_info_unit...
base/file_version_info_unittest.cc:39: const wchar_t* kExpectedValues[1][15] =
{{
On 2015/07/01 at 18:40:48, Nico wrote:
> nit: const wchar_t* const

Done.

https://codereview.chromium.org/1218243002/diff/1/base/third_party/nspr/prtim...
File base/third_party/nspr/prtime.cc (right):

https://codereview.chromium.org/1218243002/diff/1/base/third_party/nspr/prtim...
base/third_party/nspr/prtime.cc:110: SYSTEMTIME st = {};
On 2015/07/01 at 18:40:49, Nico wrote:
> This is a third-party file. Update base/third_party/README.chromium and
upstream this to nspr

It doesn't appear anyone has ever updated README.chromium other than to make
check-licenses and some other licensing stuff happy:
https://chromium.googlesource.com/chromium/src/+log/master/base/third_party/n...

In addition, upstream appears to have diverged significantly:
https://hg.mozilla.org/projects/nspr/file/cf176edf81f2/pr/src/misc/prtime.c#l229

Given that this is essentially a forked copy of prtime.c at this point, is it OK
to just keep this part as is?

[Nico, 2015-07-01 21:30:13]

lgtm, but let the base/third_party/nspr/OWNERS know I guess

[dcheng, 2015-07-01 21:36:04]

dcheng@chromium.org changed reviewers:
+ rsleevi@chromium.org

[dcheng, 2015-07-01 21:36:05]

+rsleevi for nspr changes.

[Ryan Sleevi, 2015-07-01 22:07:20]

lgtm

[Nico, 2015-07-01 22:08:11]

The CQ bit was checked by thakis@chromium.org

[commit-bot: I haz the power, 2015-07-01 22:09:27]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1218243002/20001

[commit-bot: I haz the power, 2015-07-01 22:12:22]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2015-07-01 22:12:23]

Exceeded global retry quota

[Nico, 2015-07-01 22:17:14]

I think this means "patch failed to apply". From one of these bots:

  error: patch failed: base/message_loop/message_pump_win.cc:477
  Falling back to three-way merge...
  Applied patch to 'base/message_loop/message_pump_win.cc' with conflicts.
  Applied patch base/message_loop/message_pump_win.cc cleanly.
  U base/message_loop/message_pump_win.cc

[dcheng, 2015-07-01 22:52:23]

The CQ bit was checked by dcheng@chromium.org

[dcheng, 2015-07-01 22:52:24]

The patchset sent to the CQ was uploaded after l-g-t-m from thakis@chromium.org,
rsleevi@chromium.org
Link to the patchset: https://codereview.chromium.org/1218243002/#ps40001
(title: "Rebase")

[commit-bot: I haz the power, 2015-07-01 22:52:50]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1218243002/40001

[commit-bot: I haz the power, 2015-07-02 00:07:49]

Committed patchset #3 (id:40001)

[commit-bot: I haz the power, 2015-07-02 00:08:53]

Patchset 3 (id:??) landed as
https://crrev.com/e74809cbb56e2ad906e0fbca6f97935242d3ed5f
Cr-Commit-Position: refs/heads/master@{#337139}