FBTF: Move individual XXXMsg_Params structs to a new file.

FBTF: Move individual XXXMsg_Params structs to a new file.

The new file, render_messages_params.h, is included in 57 files, while
render_messages.h is included in 176 files. Moving the Params structs to their
own file allow pruning the included headers.

(Part 2 of this cleanup will be sorting the individual structs into themes
to further minimize header inclusion.)

BUG=51411
TEST=compiles

Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=57229

[Elliot Glaysher, 2010-08-23 20:34:45]

Fun fact: with this patch, render_messages.h falls from the worst offender as
measured by headersoup to #5.

[Lei Zhang, 2010-08-23 21:01:35]

Still doesn't compile on Win32 it seems.

http://codereview.chromium.org/3119035/diff/2001/3083
File ipc/ipc_param_traits.h (right):

http://codereview.chromium.org/3119035/diff/2001/3083#newcode1
ipc/ipc_param_traits.h:1: // Copyright (c) 2010 The Chromium Authors. All rights
reserved.
Does this file need to be added to a .gyp file somewhere?

[Elliot Glaysher, 2010-08-23 21:05:41]

On 2010/08/23 21:01:35, Lei Zhang wrote:
> Still doesn't compile on Win32 it seems.

Of course not. Because the try bots bail at the first compile error, I'd guess
that I'm going to fix the one error and then repeat that cycle at least five
times.
 
> http://codereview.chromium.org/3119035/diff/2001/3083
> File ipc/ipc_param_traits.h (right):
> 
> http://codereview.chromium.org/3119035/diff/2001/3083#newcode1
> ipc/ipc_param_traits.h:1: // Copyright (c) 2010 The Chromium Authors. All
rights
> reserved.
> Does this file need to be added to a .gyp file somewhere?

Probably; it just never matters for compilation so I often forget.

[Elliot Glaysher, 2010-08-24 17:15:25]

Ping. I even have green bots. (wtf!)

[Matt Perry, 2010-08-24 17:46:39]

Doh.. I forgot to publish my comments yesterday.

http://codereview.chromium.org/3119035/diff/9001/10037
File chrome/common/common_param_traits.cc (right):

http://codereview.chromium.org/3119035/diff/9001/10037#newcode321
chrome/common/common_param_traits.cc:321: // private is so we can forward
declare net::UploadData in the header.
"so private is so" is strange phrasing. Do you mean "we define it in the .cc so
that.."?

http://codereview.chromium.org/3119035/diff/9001/10046
File chrome/common/render_messages.h (right):

http://codereview.chromium.org/3119035/diff/9001/10046#newcode78
chrome/common/render_messages.h:78: // Forward declarations of structures used
to store data for when we have a lot
What's the methodology behind what params structs get moved out of this file? I
worry that while dividing these up will improve compilation speed, it makes the
IPC system even more confusing to write to and maintain.

[Elliot Glaysher, 2010-08-24 19:46:24]

TAL

http://codereview.chromium.org/3119035/diff/9001/10037
File chrome/common/common_param_traits.cc (right):

http://codereview.chromium.org/3119035/diff/9001/10037#newcode321
chrome/common/common_param_traits.cc:321: // private is so we can forward
declare net::UploadData in the header.
On 2010/08/24 17:46:39, Matt Perry wrote:
> "so private is so" is strange phrasing. Do you mean "we define it in the .cc
so
> that.."?

Fixed. I can't C++ and English at the same time.

http://codereview.chromium.org/3119035/diff/9001/10046
File chrome/common/render_messages.h (right):

http://codereview.chromium.org/3119035/diff/9001/10046#newcode78
chrome/common/render_messages.h:78: // Forward declarations of structures used
to store data for when we have a lot
On 2010/08/24 17:46:39, Matt Perry wrote:
> What's the methodology behind what params structs get moved out of this file?
I
> worry that while dividing these up will improve compilation speed, it makes
the
> IPC system even more confusing to write to and maintain.

All param structs were moved (talked about this in person).

[Matt Perry, 2010-08-24 19:56:07]

LGTM