New IPC definitions, only applied to async ROUTED and CONTROL messages.

FBTF: New IPC definitions, only applied to async ROUTED and CONTROL messages. 

The slowest cc files in chrome include render_messages.h and other IPC message 
definitions. Including one of these files will bring in half of chrome because 
in the IPC system previously required full class definitions due to
implementation details.

The new system allows forward declarations and places the implementations of 
functions that need the full class definitions (ctor/dtor()/Log() and
superclass ctor/Read() methods) into a separate xxx_messages.cc file using a
parallel set of macros to ipc_message_macros.h. This has the added benefit
of moving most of the template instantiation junk into a small number of
files.

Pros: 
- Will speed up compiling by a lot once everything is forward declared.
- Already, intermediary .o/.a files are smaller.

Cons: 
- Adds a 4th pass to the messages system, this time in a different header. 

BUG=51411
TEST=none

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

[Elliot Glaysher, 2010-08-02 19:01:09]

+mpcomplete, +jamesr

jam looks like he's out of town, and darin hasn't gotten to reviewing the
precursor to this patch for several days. The logs show that both of you have
done ipc work before. Could you take a look?

[jamesr, 2010-08-02 20:09:58]

Made a cursory pass.  I think Matt should review this one, though, as I'm not
super familiar with the multi-pass system and work mostly in WebKit land these
days.

http://codereview.chromium.org/2873090/diff/7001/8009
File chrome/chrome_browser.gypi (right):

http://codereview.chromium.org/2873090/diff/7001/8009#newcode2892
chrome/chrome_browser.gypi:2892: # provider.
This seems pretty unfortunate.  Should these files be moved?

http://codereview.chromium.org/2873090/diff/7001/8032
File ipc/ipc_message_impl_macros.h (right):

http://codereview.chromium.org/2873090/diff/7001/8032#newcode34
ipc/ipc_message_impl_macros.h:34: // These are probalby still defined because of
ipc_message_macros.h should be
Is this comment meant as a TODO?

s/probalby/probably/

http://codereview.chromium.org/2873090/diff/7001/8032#newcode97
ipc/ipc_message_impl_macros.h:97: // Note: IPC_MESSAGE_CONTROL0 doesn't declare
anythin other then the
s/anythin/anything/

[Matt Perry, 2010-08-02 23:34:22]

Thanks for working on this! Not being able to forward declare IPC types has
always annoyed me.

You said:
'''
Because the old system uses the "typedef typename TraitsClass<A>::type Type" 
pattern with trait classes (in this case, TupleTraits), we couldn't forward 
declare A, even though nothing the IPC does in that file requires the full 
class definitions. 
'''

If that's the sole motivation for removing MessageWithTuple, I believe I have an
alternative fix. I think the fix would also apply to MessageWithReply. It would
save us a lot of mostly copy-pasted code if we could avoid getting rid of these.

The fix is to pull "ParamTuple" and friends outside of the TupleN classes. The
compiler (MSVC at least) seems to only complain that TupleN instantiates a
member variable of its template types. We can avoid that. Rewrite tuple.h as:

template <class T>
struct TupleTypes { };

template <class A>
struct Tuple1 {
 public:
  typedef A TypeA;
  // typedefs removed to below

  Tuple1() {}
  explicit Tuple1(typename TupleTraits<A>::ParamType a) : a(a) {}

  A a;
};

template <class A>
struct TupleTypes< Tuple1<A> > {
  typedef Tuple1<typename TupleTraits<A>::ValueType> ValueTuple;
  typedef Tuple1<typename TupleTraits<A>::RefType> RefTuple;
  typedef Tuple1<typename TupleTraits<A>::ParamType> ParamTuple;
};

And generalize to higher-order tuples. Then change the typedef in
MessageWithTuple to 

typedef typename TupleTypes<ParamType>::ParamTuple RefParam;

You'd also need to move the MessageWithTuple constructor out of the header files
(keep your message_impl header) since it uses the Tuple type, but from my
testing, I think these changes will work.

http://codereview.chromium.org/2873090/diff/15001/16035
File ipc/ipc_message_macros.h (right):

http://codereview.chromium.org/2873090/diff/15001/16035#newcode82
ipc/ipc_message_macros.h:82: #if defined(IPC_MESSAGE_MACROS_ENUMS)
Why did you move this here? Leaving it below the #undefs will let you get rid of
the copypasta of #undefs in each #if section.

[Elliot Glaysher, 2010-08-03 19:36:45]

I've redone the work based on your suggestions, Matt. In addition to the
ctors/dtors, the Log() method implementation also needs to be lifted out of the
interface because gcc was trying to resolve ParamType. I assume because it was a
non-templated method and needed to allocate a ParamType on the stack.

In addition, I'll try moving automation_message, per James' request.

http://codereview.chromium.org/2873090/diff/15001/16035
File ipc/ipc_message_macros.h (right):

http://codereview.chromium.org/2873090/diff/15001/16035#newcode82
ipc/ipc_message_macros.h:82: #if defined(IPC_MESSAGE_MACROS_ENUMS)
On 2010/08/02 23:34:22, Matt Perry wrote:
> Why did you move this here? Leaving it below the #undefs will let you get rid
of
> the copypasta of #undefs in each #if section.

The problem is people are including "ipc/ipc_message_macros.h" from within
xxx_messages_internal.h files. I've been unable to resolve this without changing
the timing of when we undef messages.

[Matt Perry, 2010-08-03 20:36:32]

http://codereview.chromium.org/2873090/diff/21001/22014
File chrome/common/render_messages_internal.h (right):

http://codereview.chromium.org/2873090/diff/21001/22014#newcode54
chrome/common/render_messages_internal.h:54: class WebCursor;
can we add any more forward declares for the sync messages yet?

http://codereview.chromium.org/2873090/diff/21001/22020
File ipc/ipc_message_macros.h (right):

http://codereview.chromium.org/2873090/diff/21001/22020#newcode495
ipc/ipc_message_macros.h:495: msg_class::Log(msg, params); \
rather than have to declare a static Log function for each message class, could
we just redefine this to do the Read + LogParam right here? if not, it's fine,
but it would save some copypasta if it worked.

(looks like you'd have to use the original IPC_MESSAGE_LOG for the sync
messages, though.)

http://codereview.chromium.org/2873090/diff/21001/22022
File ipc/ipc_message_utils.h (right):

http://codereview.chromium.org/2873090/diff/21001/22022#newcode1183
ipc/ipc_message_utils.h:1183: 
nit: remove extra newline

http://codereview.chromium.org/2873090/diff/21001/22024
File printing/pdf_ps_metafile_cairo.h (right):

http://codereview.chromium.org/2873090/diff/21001/22024#newcode32
printing/pdf_ps_metafile_cairo.h:32: explicit PdfPsMetafile();
no need for explicit here

[Elliot Glaysher, 2010-08-03 22:42:39]

Instead of modifying the IPC_MESSAGE_LOG() macro like you suggested, I used all
the subclass::Log() methods to pull MessageWithTuple::Read() into its own file.
subclass::Log() calls MessageWithTuple::Read(), making sure it is instantiated.

This places the reading junk in the xxx_messages.cc files and brings
libbrowser.a down to 432,780k, smaller than my original experiments where I
pulled out MessageWithTuple().

http://codereview.chromium.org/2873090/diff/21001/22014
File chrome/common/render_messages_internal.h (right):

http://codereview.chromium.org/2873090/diff/21001/22014#newcode54
chrome/common/render_messages_internal.h:54: class WebCursor;
On 2010/08/03 20:36:32, Matt Perry wrote:
> can we add any more forward declares for the sync messages yet?

Not here at least. Once I fix the the sync messages, everything that doesn't use
internal classes should be forward declarable though. I will probably do that in
two parts: 1) A patch that fixes all the sync messages along with one or two
forward declares to show that it is possible. 2) The forward declaration
megapatch.

[Matt Perry, 2010-08-03 22:54:06]

LGTM.

http://codereview.chromium.org/2873090/diff/33001/59
File ipc/ipc_message_impl_macros.h (right):

http://codereview.chromium.org/2873090/diff/33001/59#newcode12
ipc/ipc_message_impl_macros.h:12: // pass. But we *still* can't use normal
include guards because we still need
I don't follow why we can't wrap this header with a header guard. If it's only
included once, a guard should have no effect, right?

http://codereview.chromium.org/2873090/diff/33001/62
File ipc/ipc_message_utils.h (right):

http://codereview.chromium.org/2873090/diff/33001/62#newcode1030
ipc/ipc_message_utils.h:1030: // ipc_message_utils_impl.h. They subclass
constructor and Log() methods call
The*