Make a bunch of structs anonymous ...

Make a bunch of structs anonymous ...

... instead of naming them just so that arraysize can be used (instead
of ARRAYSIZE_UNSAFE), since C++11 removes this restriction. Also remove
some comments about this.

(Note that the change was automatically formatted, as required by the
presubmit check. Arguably, the entire file should be reformatted for
consistency, but that should be done separately.)

R=ajuma@chromium.org
BUG=423134
Committed: https://crrev.com/f4f532e27b9130fab6da3d1c08216222fc8b5f87
Cr-Commit-Position: refs/heads/master@{#299989}

[ajuma, 2014-10-16 19:49:20]

lgtm

[danakj, 2014-10-16 20:08:02]

danakj@chromium.org changed reviewers:
+ danakj@chromium.org

[danakj, 2014-10-16 20:08:02]

https://codereview.chromium.org/660103002/diff/1/cc/animation/transform_opera...
File cc/animation/transform_operations_unittest.cc (right):

https://codereview.chromium.org/660103002/diff/1/cc/animation/transform_opera...
cc/animation/transform_operations_unittest.cc:1177: };
this is super weird, mind filing a clang-format bug about this ali?

[jamesr, 2014-10-16 20:43:08]

jamesr@chromium.org changed reviewers:
+ jamesr@chromium.org

[jamesr, 2014-10-16 20:43:09]

https://codereview.chromium.org/660103002/diff/1/cc/animation/transform_opera...
File cc/animation/transform_operations_unittest.cc (right):

https://codereview.chromium.org/660103002/diff/1/cc/animation/transform_opera...
cc/animation/transform_operations_unittest.cc:1177: };
On 2014/10/16 20:08:02, danakj wrote:
> this is super weird, mind filing a clang-format bug about this ali?

I don't see the issue.  The declaration here starts on column 5

skews[] ...

and the }; matches the start of the declaration.

[danakj, 2014-10-16 20:50:27]

https://codereview.chromium.org/660103002/diff/1/cc/animation/transform_opera...
File cc/animation/transform_operations_unittest.cc (right):

https://codereview.chromium.org/660103002/diff/1/cc/animation/transform_opera...
cc/animation/transform_operations_unittest.cc:1177: };
On 2014/10/16 20:43:09, jamesr wrote:
> On 2014/10/16 20:08:02, danakj wrote:
> > this is super weird, mind filing a clang-format bug about this ali?
> 
> I don't see the issue.  The declaration here starts on column 5
> 
> skews[] ...
> 
> and the }; matches the start of the declaration.

i expect the } to be at the level of indent of the block it returns to i guess

like

} else {
}

not 

} else {
  }

[jamesr, 2014-10-16 20:55:21]

On 2014/10/16 20:50:27, danakj wrote:
>
https://codereview.chromium.org/660103002/diff/1/cc/animation/transform_opera...
> File cc/animation/transform_operations_unittest.cc (right):
> 
>
https://codereview.chromium.org/660103002/diff/1/cc/animation/transform_opera...
> cc/animation/transform_operations_unittest.cc:1177: };
> On 2014/10/16 20:43:09, jamesr wrote:
> > On 2014/10/16 20:08:02, danakj wrote:
> > > this is super weird, mind filing a clang-format bug about this ali?
> > 
> > I don't see the issue.  The declaration here starts on column 5
> > 
> > skews[] ...
> > 
> > and the }; matches the start of the declaration.
> 
> i expect the } to be at the level of indent of the block it returns to i guess
> 
> like
> 
> } else {
> }
> 
> not 
> 
> } else {
>   }

The struct definition block starts on column 3 and ends on column 3.  The
initializer for the list of structs starts on column 5 and ends on column 5.  If
the initializer started on column 3 it'd end on 3, but it doesn't.

[danakj, 2014-10-16 21:03:45]

On Thu, Oct 16, 2014 at 4:55 PM, <jamesr@chromium.org> wrote:

> On 2014/10/16 20:50:27, danakj wrote:
>
> https://codereview.chromium.org/660103002/diff/1/cc/animation/transform_
> operations_unittest.cc
>
>> File cc/animation/transform_operations_unittest.cc (right):
>>
>
>
> https://codereview.chromium.org/660103002/diff/1/cc/animation/transform_
> operations_unittest.cc#newcode1177
>
>> cc/animation/transform_operations_unittest.cc:1177: };
>> On 2014/10/16 20:43:09, jamesr wrote:
>> > On 2014/10/16 20:08:02, danakj wrote:
>> > > this is super weird, mind filing a clang-format bug about this ali?
>> >
>> > I don't see the issue.  The declaration here starts on column 5
>> >
>> > skews[] ...
>> >
>> > and the }; matches the start of the declaration.
>>
>
>  i expect the } to be at the level of indent of the block it returns to i
>> guess
>>
>
>  like
>>
>
>  } else {
>> }
>>
>
>  not
>>
>
>  } else {
>>    }
>>
>
> The struct definition block starts on column 3 and ends on column 3.  The
> initializer for the list of structs starts on column 5 and ends on column
> 5.  If
> the initializer started on column 3 it'd end on 3, but it doesn't.
>

I don't see any case of formatting this way in g3, and plenty of examples
otherwise. I still don't think this is right.

To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[danakj, 2014-10-16 21:06:58]

I filed b/18019543

On Thu, Oct 16, 2014 at 5:03 PM, Dana Jansens <danakj@chromium.org> wrote:

> On Thu, Oct 16, 2014 at 4:55 PM, <jamesr@chromium.org> wrote:
>
>> On 2014/10/16 20:50:27, danakj wrote:
>>
>> https://codereview.chromium.org/660103002/diff/1/cc/animation/transform_
>> operations_unittest.cc
>>
>>> File cc/animation/transform_operations_unittest.cc (right):
>>>
>>
>>
>> https://codereview.chromium.org/660103002/diff/1/cc/animation/transform_
>> operations_unittest.cc#newcode1177
>>
>>> cc/animation/transform_operations_unittest.cc:1177: };
>>> On 2014/10/16 20:43:09, jamesr wrote:
>>> > On 2014/10/16 20:08:02, danakj wrote:
>>> > > this is super weird, mind filing a clang-format bug about this ali?
>>> >
>>> > I don't see the issue.  The declaration here starts on column 5
>>> >
>>> > skews[] ...
>>> >
>>> > and the }; matches the start of the declaration.
>>>
>>
>>  i expect the } to be at the level of indent of the block it returns to i
>>> guess
>>>
>>
>>  like
>>>
>>
>>  } else {
>>> }
>>>
>>
>>  not
>>>
>>
>>  } else {
>>>    }
>>>
>>
>> The struct definition block starts on column 3 and ends on column 3.  The
>> initializer for the list of structs starts on column 5 and ends on column
>> 5.  If
>> the initializer started on column 3 it'd end on 3, but it doesn't.
>>
>
> I don't see any case of formatting this way in g3, and plenty of examples
> otherwise. I still don't think this is right.
>

To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[viettrungluu, 2014-10-16 21:35:44]

The CQ bit was checked by viettrungluu@chromium.org

[commit-bot: I haz the power, 2014-10-16 21:38:01]

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

[commit-bot: I haz the power, 2014-10-16 22:10:14]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2014-10-16 22:11:01]

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