[Bindings] [Reformat] Reformat template files

Reformat template files to match with more of Chromium style guide.
- default indent: 2 spaces
- public:/private: in class definitions are indented by 1-space
- indent 'case X:' lines and its content lines more
- move open braces to the line of function/method name
- 2 spaces before inline comments
- Use CHECK() macros instead of ASSERT() macros

Beside it, this CL ignores the 80-characters column
limit because it depends on what values/arguments are used.



BUG=None

[peria, 2016-10-25 15:29:30]

Patchset #1 (id:1) has been deleted

[peria, 2016-10-25 15:32:37]

Description was changed from

==========
Reformat template files
- PS1: indents and braces

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

to

==========
Reformat template files for limited rules
- change indents 4=>2 spaces.
- move open braces to the function/method name definition.

On the other hand, this CL ignores the 80-characters column
limit because it depends on what values/arguments are used.


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

[peria, 2016-10-25 15:37:06]

Description was changed from

==========
Reformat template files for limited rules
- change indents 4=>2 spaces.
- move open braces to the function/method name definition.

On the other hand, this CL ignores the 80-characters column
limit because it depends on what values/arguments are used.


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

to

==========
Reformat template files to match with more of Chromium style guide.
- default indent: 2 spaces
- public:/private: in class definitions are indented by 1-space
- indent 'case X:' lines and its content lines more
- move open braces to the line of function/method name


On the other hand, this CL ignores the 80-characters column
limit because it depends on what values/arguments are used.


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

[peria, 2016-10-25 16:38:24]

Description was changed from

==========
Reformat template files to match with more of Chromium style guide.
- default indent: 2 spaces
- public:/private: in class definitions are indented by 1-space
- indent 'case X:' lines and its content lines more
- move open braces to the line of function/method name


On the other hand, this CL ignores the 80-characters column
limit because it depends on what values/arguments are used.


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

to

==========
Reformat template files to match with more of Chromium style guide.
- default indent: 2 spaces
- public:/private: in class definitions are indented by 1-space
- indent 'case X:' lines and its content lines more
- move open braces to the line of function/method name
- 2 spaces before inline comments


On the other hand, this CL ignores the 80-characters column
limit because it depends on what values/arguments are used.


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

[peria, 2016-10-25 16:42:16]

Description was changed from

==========
Reformat template files to match with more of Chromium style guide.
- default indent: 2 spaces
- public:/private: in class definitions are indented by 1-space
- indent 'case X:' lines and its content lines more
- move open braces to the line of function/method name
- 2 spaces before inline comments


On the other hand, this CL ignores the 80-characters column
limit because it depends on what values/arguments are used.


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

to

==========
Reformat template files to match with more of Chromium style guide.
- default indent: 2 spaces
- public:/private: in class definitions are indented by 1-space
- indent 'case X:' lines and its content lines more
- move open braces to the line of function/method name
- 2 spaces before inline comments

Beside it, this CL ignores the 80-characters column
limit because it depends on what values/arguments are used.


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

[peria, 2016-10-25 17:16:48]

Description was changed from

==========
Reformat template files to match with more of Chromium style guide.
- default indent: 2 spaces
- public:/private: in class definitions are indented by 1-space
- indent 'case X:' lines and its content lines more
- move open braces to the line of function/method name
- 2 spaces before inline comments

Beside it, this CL ignores the 80-characters column
limit because it depends on what values/arguments are used.


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

to

==========
Reformat template files to match with more of Chromium style guide.
- default indent: 2 spaces
- public:/private: in class definitions are indented by 1-space
- indent 'case X:' lines and its content lines more
- move open braces to the line of function/method name
- 2 spaces before inline comments
- Use CHECK() macros instead of ASSERT() macros

Beside it, this CL ignores the 80-characters column
limit because it depends on what values/arguments are used.


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

[peria, 2016-10-25 17:17:00]

Patchset #1 (id:10001) has been deleted

[peria, 2016-10-25 17:18:45]

peria@chromium.org changed reviewers:
+ bashi@chromium.org, haraken@chromium.org, yukishiino@chromium.org

[peria, 2016-10-25 17:18:46]

PTL.

I recommend to check .tmpl files and random sampling check of generated files.

[Yuki, 2016-10-25 17:22:18]

lgtm

[haraken, 2016-10-25 17:34:00]

rs LGTM

[bashi, 2016-10-25 23:19:17]

rs-lgtm

[peria, 2016-10-26 04:00:59]

The CQ bit was checked by peria@chromium.org

[commit-bot: I haz the power, 2016-10-26 04:02:00]

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

[commit-bot: I haz the power, 2016-10-26 04:15:13]

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

[commit-bot: I haz the power, 2016-10-26 04:15:15]

Try jobs failed on following builders:
  chromium_presubmit on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/chromium_presub...)

[peria, 2016-10-26 05:48:56]

Hmm. tests/results/core/V8TestObject.cpp has a huge diff (17157 lines?)
and filed to upload it.

[peria, 2016-10-26 07:39:52]

On 2016/10/26 05:48:56, peria wrote:
> Hmm. tests/results/core/V8TestObject.cpp has a huge diff (17157 lines?)
> and filed to upload it.

s/filed/failed/

Do you know how I can upload and patch this CL?
Or should I split this into acceptable sized CLs?

[Yuki, 2016-10-26 07:42:19]

On 2016/10/26 07:39:52, peria wrote:
> On 2016/10/26 05:48:56, peria wrote:
> > Hmm. tests/results/core/V8TestObject.cpp has a huge diff (17157 lines?)
> > and filed to upload it.
> 
> s/filed/failed/
> 
> Do you know how I can upload and patch this CL?
> Or should I split this into acceptable sized CLs?

Probably we're putting too many things in TestObject.idl?
Should we consider split things in TestObject.idl into pieces?

[haraken, 2016-10-26 07:43:07]

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

[haraken, 2016-10-26 07:43:08]

+dcheng: How to upload a giant size CL to the code review.

peria@: In short term you might want to dcommit the  CL.

[Yuki, 2016-10-26 07:43:20]

On 2016/10/26 07:42:19, Yuki wrote:
> On 2016/10/26 07:39:52, peria wrote:
> > On 2016/10/26 05:48:56, peria wrote:
> > > Hmm. tests/results/core/V8TestObject.cpp has a huge diff (17157 lines?)
> > > and filed to upload it.
> > 
> > s/filed/failed/
> > 
> > Do you know how I can upload and patch this CL?
> > Or should I split this into acceptable sized CLs?
> 
> Probably we're putting too many things in TestObject.idl?
> Should we consider split things in TestObject.idl into pieces?

Ah, if the total byte size in a single CL matters, this doesn't help at all.

[dcheng, 2016-10-26 07:46:22]

On 2016/10/26 07:43:20, Yuki wrote:
> On 2016/10/26 07:42:19, Yuki wrote:
> > On 2016/10/26 07:39:52, peria wrote:
> > > On 2016/10/26 05:48:56, peria wrote:
> > > > Hmm. tests/results/core/V8TestObject.cpp has a huge diff (17157 lines?)
> > > > and filed to upload it.
> > > 
> > > s/filed/failed/
> > > 
> > > Do you know how I can upload and patch this CL?
> > > Or should I split this into acceptable sized CLs?
> > 
> > Probably we're putting too many things in TestObject.idl?
> > Should we consider split things in TestObject.idl into pieces?
> 
> Ah, if the total byte size in a single CL matters, this doesn't help at all.

For the blink reformat, we just used git cl land. Since the diffs we can't
upload are in generated code, it seems OK to proceed with that.

[dcheng, 2016-10-26 07:47:12]

On 2016/10/26 07:46:22, dcheng wrote:
> On 2016/10/26 07:43:20, Yuki wrote:
> > On 2016/10/26 07:42:19, Yuki wrote:
> > > On 2016/10/26 07:39:52, peria wrote:
> > > > On 2016/10/26 05:48:56, peria wrote:
> > > > > Hmm. tests/results/core/V8TestObject.cpp has a huge diff (17157
lines?)
> > > > > and filed to upload it.
> > > > 
> > > > s/filed/failed/
> > > > 
> > > > Do you know how I can upload and patch this CL?
> > > > Or should I split this into acceptable sized CLs?
> > > 
> > > Probably we're putting too many things in TestObject.idl?
> > > Should we consider split things in TestObject.idl into pieces?
> > 
> > Ah, if the total byte size in a single CL matters, this doesn't help at all.
> 
> For the blink reformat, we just used git cl land. Since the diffs we can't
> upload are in generated code, it seems OK to proceed with that.

P.S. I am totally not looking forward to this rebase in my local CLs =P

[peria, 2016-10-26 07:48:09]

On 2016/10/26 07:43:20, Yuki wrote:
> On 2016/10/26 07:42:19, Yuki wrote:
> > On 2016/10/26 07:39:52, peria wrote:
> > > On 2016/10/26 05:48:56, peria wrote:
> > > > Hmm. tests/results/core/V8TestObject.cpp has a huge diff (17157 lines?)
> > > > and filed to upload it.
> > > 
> > > s/filed/failed/
> > > 
> > > Do you know how I can upload and patch this CL?
> > > Or should I split this into acceptable sized CLs?
> > 
> > Probably we're putting too many things in TestObject.idl?
> > Should we consider split things in TestObject.idl into pieces?
> 
> Ah, if the total byte size in a single CL matters, this doesn't help at all.

Thank you for your advice!
I think I don't have to hurry up, and think it better each IDL file focus on
some feature, so I follow Shiino-san's suggestion. (Split TestObject.idl int
pieces)
It may help future changes in IDL compilers which change styles in TestObject.

[bashi, 2016-10-26 07:51:43]

On 2016/10/26 07:48:09, peria wrote:
> On 2016/10/26 07:43:20, Yuki wrote:
> > On 2016/10/26 07:42:19, Yuki wrote:
> > > On 2016/10/26 07:39:52, peria wrote:
> > > > On 2016/10/26 05:48:56, peria wrote:
> > > > > Hmm. tests/results/core/V8TestObject.cpp has a huge diff (17157
lines?)
> > > > > and filed to upload it.
> > > > 
> > > > s/filed/failed/
> > > > 
> > > > Do you know how I can upload and patch this CL?
> > > > Or should I split this into acceptable sized CLs?
> > > 
> > > Probably we're putting too many things in TestObject.idl?
> > > Should we consider split things in TestObject.idl into pieces?
> > 
> > Ah, if the total byte size in a single CL matters, this doesn't help at all.
> 
> Thank you for your advice!
> I think I don't have to hurry up, and think it better each IDL file focus on
> some feature, so I follow Shiino-san's suggestion. (Split TestObject.idl int
> pieces)
> It may help future changes in IDL compilers which change styles in TestObject.

I support splitting IDL files but we've avoided adding IDL files for testing. I
have no idea but there might be some reasons.

[haraken, 2016-10-26 07:52:35]

On 2016/10/26 07:48:09, peria wrote:
> On 2016/10/26 07:43:20, Yuki wrote:
> > On 2016/10/26 07:42:19, Yuki wrote:
> > > On 2016/10/26 07:39:52, peria wrote:
> > > > On 2016/10/26 05:48:56, peria wrote:
> > > > > Hmm. tests/results/core/V8TestObject.cpp has a huge diff (17157
lines?)
> > > > > and filed to upload it.
> > > > 
> > > > s/filed/failed/
> > > > 
> > > > Do you know how I can upload and patch this CL?
> > > > Or should I split this into acceptable sized CLs?
> > > 
> > > Probably we're putting too many things in TestObject.idl?
> > > Should we consider split things in TestObject.idl into pieces?
> > 
> > Ah, if the total byte size in a single CL matters, this doesn't help at all.
> 
> Thank you for your advice!
> I think I don't have to hurry up, and think it better each IDL file focus on
> some feature, so I follow Shiino-san's suggestion. (Split TestObject.idl int
> pieces)
> It may help future changes in IDL compilers which change styles in TestObject.

As shiino-san noted,

[haraken, 2016-10-26 07:53:10]

On 2016/10/26 07:52:35, haraken wrote:
> On 2016/10/26 07:48:09, peria wrote:
> > On 2016/10/26 07:43:20, Yuki wrote:
> > > On 2016/10/26 07:42:19, Yuki wrote:
> > > > On 2016/10/26 07:39:52, peria wrote:
> > > > > On 2016/10/26 05:48:56, peria wrote:
> > > > > > Hmm. tests/results/core/V8TestObject.cpp has a huge diff (17157
> lines?)
> > > > > > and filed to upload it.
> > > > > 
> > > > > s/filed/failed/
> > > > > 
> > > > > Do you know how I can upload and patch this CL?
> > > > > Or should I split this into acceptable sized CLs?
> > > > 
> > > > Probably we're putting too many things in TestObject.idl?
> > > > Should we consider split things in TestObject.idl into pieces?
> > > 
> > > Ah, if the total byte size in a single CL matters, this doesn't help at
all.
> > 
> > Thank you for your advice!
> > I think I don't have to hurry up, and think it better each IDL file focus on
> > some feature, so I follow Shiino-san's suggestion. (Split TestObject.idl int
> > pieces)
> > It may help future changes in IDL compilers which change styles in
TestObject.
> 
> As shiino-san noted,

As shiino-san noted, splitting TestObject won't help reduce the size of  CLs
like this.

[haraken, 2016-10-26 07:55:55]

On 2016/10/26 07:51:43, bashi1 wrote:
> On 2016/10/26 07:48:09, peria wrote:
> > On 2016/10/26 07:43:20, Yuki wrote:
> > > On 2016/10/26 07:42:19, Yuki wrote:
> > > > On 2016/10/26 07:39:52, peria wrote:
> > > > > On 2016/10/26 05:48:56, peria wrote:
> > > > > > Hmm. tests/results/core/V8TestObject.cpp has a huge diff (17157
> lines?)
> > > > > > and filed to upload it.
> > > > > 
> > > > > s/filed/failed/
> > > > > 
> > > > > Do you know how I can upload and patch this CL?
> > > > > Or should I split this into acceptable sized CLs?
> > > > 
> > > > Probably we're putting too many things in TestObject.idl?
> > > > Should we consider split things in TestObject.idl into pieces?
> > > 
> > > Ah, if the total byte size in a single CL matters, this doesn't help at
all.
> > 
> > Thank you for your advice!
> > I think I don't have to hurry up, and think it better each IDL file focus on
> > some feature, so I follow Shiino-san's suggestion. (Split TestObject.idl int
> > pieces)
> > It may help future changes in IDL compilers which change styles in
TestObject.
> 
> I support splitting IDL files but we've avoided adding IDL files for testing.
I
> have no idea but there might be some reasons.

The reason is that # of IDL files will just increase # of lines of generated
code, which will increase the CL size.

I don't have any strong opinion about splitting if it's important for something,
but it doesn't make sense to split it for reducing the CL size. It will increase
the CL size.

[peria, 2016-10-26 08:01:31]

On 2016/10/26 07:53:10, haraken wrote:
> On 2016/10/26 07:52:35, haraken wrote:
> > On 2016/10/26 07:48:09, peria wrote:
> > > On 2016/10/26 07:43:20, Yuki wrote:
> > > > On 2016/10/26 07:42:19, Yuki wrote:
> > > > > On 2016/10/26 07:39:52, peria wrote:
> > > > > > On 2016/10/26 05:48:56, peria wrote:
> > > > > > > Hmm. tests/results/core/V8TestObject.cpp has a huge diff (17157
> > lines?)
> > > > > > > and filed to upload it.
> > > > > > 
> > > > > > s/filed/failed/
> > > > > > 
> > > > > > Do you know how I can upload and patch this CL?
> > > > > > Or should I split this into acceptable sized CLs?
> > > > > 
> > > > > Probably we're putting too many things in TestObject.idl?
> > > > > Should we consider split things in TestObject.idl into pieces?
> > > > 
> > > > Ah, if the total byte size in a single CL matters, this doesn't help at
> all.
> > > 
> > > Thank you for your advice!
> > > I think I don't have to hurry up, and think it better each IDL file focus
on
> > > some feature, so I follow Shiino-san's suggestion. (Split TestObject.idl
int
> > > pieces)
> > > It may help future changes in IDL compilers which change styles in
> TestObject.
> > 
> > As shiino-san noted,
> 
> As shiino-san noted, splitting TestObject won't help reduce the size of  CLs
> like this.

Let me confirm.
I think submitting this CL failed because V8TestObject.cpp had no diff in this
CL while it was changed, not because of the total size of this CL.
And it was not uploaded because the diff of the file was too large.
(I think this is an issue of git-cl.)

If the total size of CL is the cause, we can submit this with `git cl land`
as Daniel said.

[haraken, 2016-10-26 08:10:01]

On 2016/10/26 08:01:31, peria wrote:
> On 2016/10/26 07:53:10, haraken wrote:
> > On 2016/10/26 07:52:35, haraken wrote:
> > > On 2016/10/26 07:48:09, peria wrote:
> > > > On 2016/10/26 07:43:20, Yuki wrote:
> > > > > On 2016/10/26 07:42:19, Yuki wrote:
> > > > > > On 2016/10/26 07:39:52, peria wrote:
> > > > > > > On 2016/10/26 05:48:56, peria wrote:
> > > > > > > > Hmm. tests/results/core/V8TestObject.cpp has a huge diff (17157
> > > lines?)
> > > > > > > > and filed to upload it.
> > > > > > > 
> > > > > > > s/filed/failed/
> > > > > > > 
> > > > > > > Do you know how I can upload and patch this CL?
> > > > > > > Or should I split this into acceptable sized CLs?
> > > > > > 
> > > > > > Probably we're putting too many things in TestObject.idl?
> > > > > > Should we consider split things in TestObject.idl into pieces?
> > > > > 
> > > > > Ah, if the total byte size in a single CL matters, this doesn't help
at
> > all.
> > > > 
> > > > Thank you for your advice!
> > > > I think I don't have to hurry up, and think it better each IDL file
focus
> on
> > > > some feature, so I follow Shiino-san's suggestion. (Split TestObject.idl
> int
> > > > pieces)
> > > > It may help future changes in IDL compilers which change styles in
> > TestObject.
> > > 
> > > As shiino-san noted,
> > 
> > As shiino-san noted, splitting TestObject won't help reduce the size of  CLs
> > like this.
> 
> Let me confirm.
> I think submitting this CL failed because V8TestObject.cpp had no diff in this
> CL while it was changed, not because of the total size of this CL.
> And it was not uploaded because the diff of the file was too large.
> (I think this is an issue of git-cl.)
> 
> If the total size of CL is the cause, we can submit this with `git cl land`
> as Daniel said.

Ah, got it. Then I'm okay with splitting (but I'd prefer not splitting it into
too many pieces since it will increase the size of regular CLs that touch the
IDL compiler).

[peria, 2016-10-26 08:12:42]

On 2016/10/26 07:51:43, bashi1 wrote:
> On 2016/10/26 07:48:09, peria wrote:
> > On 2016/10/26 07:43:20, Yuki wrote:
> > > On 2016/10/26 07:42:19, Yuki wrote:
> > > > On 2016/10/26 07:39:52, peria wrote:
> > > > > On 2016/10/26 05:48:56, peria wrote:
> > > > > > Hmm. tests/results/core/V8TestObject.cpp has a huge diff (17157
> lines?)
> > > > > > and filed to upload it.
> > > > > 
> > > > > s/filed/failed/
> > > > > 
> > > > > Do you know how I can upload and patch this CL?
> > > > > Or should I split this into acceptable sized CLs?
> > > > 
> > > > Probably we're putting too many things in TestObject.idl?
> > > > Should we consider split things in TestObject.idl into pieces?
> > > 
> > > Ah, if the total byte size in a single CL matters, this doesn't help at
all.
> > 
> > Thank you for your advice!
> > I think I don't have to hurry up, and think it better each IDL file focus on
> > some feature, so I follow Shiino-san's suggestion. (Split TestObject.idl int
> > pieces)
> > It may help future changes in IDL compilers which change styles in
TestObject.
> 
> I support splitting IDL files but we've avoided adding IDL files for testing.
I
> have no idea but there might be some reasons.

IIUC, adding test IDL files can increase time for pre-submit, but I think it is
short enough for human (<100ms?) and not problematic.

[peria, 2016-10-26 08:15:49]

Description was changed from

==========
Reformat template files to match with more of Chromium style guide.
- default indent: 2 spaces
- public:/private: in class definitions are indented by 1-space
- indent 'case X:' lines and its content lines more
- move open braces to the line of function/method name
- 2 spaces before inline comments
- Use CHECK() macros instead of ASSERT() macros

Beside it, this CL ignores the 80-characters column
limit because it depends on what values/arguments are used.


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

to

==========
Reformat template files to match with more of Chromium style guide.
- default indent: 2 spaces
- public:/private: in class definitions are indented by 1-space
- indent 'case X:' lines and its content lines more
- move open braces to the line of function/method name
- 2 spaces before inline comments
- Use CHECK() macros instead of ASSERT() macros

Beside it, this CL ignores the 80-characters column
limit because it depends on what values/arguments are used.

TODO: Split TestObject.idl small enogh to be uploaded.


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

[peria, 2016-10-28 18:25:10]

Description was changed from

==========
Reformat template files to match with more of Chromium style guide.
- default indent: 2 spaces
- public:/private: in class definitions are indented by 1-space
- indent 'case X:' lines and its content lines more
- move open braces to the line of function/method name
- 2 spaces before inline comments
- Use CHECK() macros instead of ASSERT() macros

Beside it, this CL ignores the 80-characters column
limit because it depends on what values/arguments are used.

TODO: Split TestObject.idl small enogh to be uploaded.


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

to

==========
Reformat template files to match with more of Chromium style guide.
- default indent: 2 spaces
- public:/private: in class definitions are indented by 1-space
- indent 'case X:' lines and its content lines more
- move open braces to the line of function/method name
- 2 spaces before inline comments
- Use CHECK() macros instead of ASSERT() macros

Beside it, this CL ignores the 80-characters column
limit because it depends on what values/arguments are used.



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

[peria, 2016-10-28 18:26:17]

This CL was splitted into 4 CLs
https://codereview.chromium.org/2454133002/
https://codereview.chromium.org/2460563002/
https://codereview.chromium.org/2449043007/
https://codereview.chromium.org/2452403002/
and they were committed.
So let me close this CL.