Clean formatting after http://crrev.com/2544803002/.

Clean formatting after http://crrev.com/2544803002/.

As recommended, reformat the array definition (locally disable
clang-format) and use range-base loop (as it works with plain
arrays).

BUG=None

Committed: https://crrev.com/cdeaacd4acb0467526ea9a4ce27859f731417b6c
Cr-Commit-Position: refs/heads/master@{#436902}

[sdefresne, 2016-12-06 12:04:23]

The CQ bit was checked by sdefresne@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-12-06 12:04:33]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[sdefresne, 2016-12-06 12:05:41]

sdefresne@chromium.org changed reviewers:
+ dpranke@chromium.org

[sdefresne, 2016-12-06 12:05:42]

Please take a look and send to CQ if LGTY.

[commit-bot: I haz the power, 2016-12-06 12:43:10]

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

[commit-bot: I haz the power, 2016-12-06 12:43:11]

Dry run: This issue passed the CQ dry run.

[Dirk Pranke, 2016-12-06 20:16:34]

lgtm. If clang-format produced the prior formatting, that looks like a bug to
me. Mind filing one and cc'ing thakis@ and nick@ ?

[sdefresne, 2016-12-07 09:48:28]

The CQ bit was checked by sdefresne@chromium.org

[commit-bot: I haz the power, 2016-12-07 09:48:42]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[sdefresne, 2016-12-07 09:48:47]

On 2016/12/06 20:16:34, Dirk Pranke wrote:
> lgtm. If clang-format produced the prior formatting, that looks like a bug to
> me. Mind filing one and cc'ing thakis@ and nick@ ?

Issue reported (you are in cc: with thakis@ but I could not find nick@)

[commit-bot: I haz the power, 2016-12-07 09:52:09]

CQ is committing da patch.

Bot data: {"patchset_id": 1, "attempt_start_ts": 1481104108275590, "parent_rev":
"721e076a94305cd8a628ee9e3195d3e9833e6502", "commit_rev":
"d5b1125f274af94cb5f034a443fbd0a65fe0a97d"}

[commit-bot: I haz the power, 2016-12-07 09:52:44]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2016-12-07 09:55:07]

Description was changed from

==========
Clean formatting after http://crrev.com/2544803002/.

As recommended, reformat the array definition (locally disable
clang-format) and use range-base loop (as it works with plain
arrays).

BUG=None
==========

to

==========
Clean formatting after http://crrev.com/2544803002/.

As recommended, reformat the array definition (locally disable
clang-format) and use range-base loop (as it works with plain
arrays).

BUG=None

Committed: https://crrev.com/cdeaacd4acb0467526ea9a4ce27859f731417b6c
Cr-Commit-Position: refs/heads/master@{#436902}
==========

[commit-bot: I haz the power, 2016-12-07 09:55:08]

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

[Nico, 2016-12-07 15:29:23]

On 2016/12/06 20:16:34, Dirk Pranke wrote:
> lgtm. If clang-format produced the prior formatting, that looks like a bug to
> me. Mind filing one and cc'ing thakis@ and nick@ ?

Is the bug the excess of spaces, or that it puts more than one of these on one
line? If the former, that does seem like the bug. If the latter, I'd like to
argue that it isn't.

[Dirk Pranke, 2016-12-07 15:38:01]

On 2016/12/07 15:29:23, Nico wrote:
> Is the bug the excess of spaces, or that it puts more than one of these on one
> line? If the former, that does seem like the bug. If the latter, I'd like to
> argue that it isn't.

The excess spaces.

[Nico, 2016-12-08 19:55:18]

On 2016/12/07 15:38:01, Dirk Pranke wrote:
> On 2016/12/07 15:29:23, Nico wrote:
> > Is the bug the excess of spaces, or that it puts more than one of these on
one
> > line? If the former, that does seem like the bug. If the latter, I'd like to
> > argue that it isn't.
> 
> The excess spaces.

Per internal bug, that's because clang-format tries to align columns, even if
there's only one row with aligned columns. I agree that this looks weird, and it
sounds like it will be fixed.

Having said that, I don't think this warrants a clang-format off override.
Adding this has a real cost: If someone does an automatic refactoring, they
either have to manually update this block, or (more likely) they won't think of
having to check for these blocks and it'll look worse than without the
clang-format off block after the rewriting. So I'd recommend reverting this.

[Dirk Pranke, 2016-12-08 20:09:24]

Agreed, I'm fine with (and prefer) weird formatting if there's a clang-format
bug on file for it.