NO CODE CHANGE.

chrome/common/ipc_message_macros.h

 // Copyright (c) 2006-2008 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 // This header is meant to be included in multiple passes, hence no traditional
 // header guard.
 //
 // In the first pass, IPC_MESSAGE_MACROS_ENUMS should be defined, which will
 // create enums for each of the messages defined with the IPC_MESSAGE_* macros.
 //
 // In the second pass, either IPC_MESSAGE_MACROS_DEBUGSTRINGS or
 // IPC_MESSAGE_MACROS_CLASSES should be defined (if both, DEBUGSTRINGS takes
 // precedence).  Only one .cc file should have DEBUGSTRINGS defined, as this
 // will create helper functions mapping message types to strings.  Having
 // CLASSES defined will create classes for each of the messages defined with
 // the IPC_MESSAGE_* macros.
 //
 // "Sync" messages are just synchronous calls, the Send() call doesn't return
 // until a reply comes back.  Input parameters are first (const TYPE&), and
 // To declare a sync message, use the IPC_SYNC_ macros.  The numbers at the
-// end show how many input/output parameters there are (i.e. 1_2 is 1 in, 2 out).
-// The caller does a Send([route id, ], in1, &out1, &out2).
+// end show how many input/output parameters there are (i.e. 1_2 is 1 in, 2
+// out). The caller does a Send([route id, ], in1, &out1, &out2).
 // The receiver's handler function will be
 //     void OnSyncMessageName(const type1& in1, type2* out1, type3* out2)
 //
 //
 // A caller can also send a synchronous message, while the receiver can respond
 // at a later time.  This is transparent from the sender's size.  The receiver
 // needs to use a different handler that takes in a IPC::Message* as the output
 // type, stash the message, and when it has the data it can Send the message.
 //
 // Use the IPC_MESSAGE_HANDLER_DELAY_REPLY macro instead of IPC_MESSAGE_HANDLER
-//     IPC_MESSAGE_HANDLER_DELAY_REPLY(ViewHostMsg_SyncMessageName, OnSyncMessageName)
+//     IPC_MESSAGE_HANDLER_DELAY_REPLY(ViewHostMsg_SyncMessageName,
+//                                     OnSyncMessageName)
 //
 // The handler function will look like:
 //     void OnSyncMessageName(const type1& in1, IPC::Message* reply_msg);
 //
 // Receiver stashes the IPC::Message* pointer, and when it's ready, it does:
 //     ViewHostMsg_SyncMessageName::WriteReplyParams(reply_msg, out1, out2);
 //     Send(reply_msg);
 
 #include "chrome/common/ipc_message_utils.h"
 
@@ skipping 89 matching lines @@
 #undef IPC_SYNC_MESSAGE_ROUTED4_2
 
 #if defined(IPC_MESSAGE_MACROS_ENUMS)
 #undef IPC_MESSAGE_MACROS_ENUMS
 
 // TODO(jabdelmalek): we're using the lowest 12 bits of type for the message
 // id, and the highest 4 bits for the channel type.  This constrains us to
 // 16 channel types (currently using 8) and 4K messages per type.  Should
 // really make type be 32 bits, but then we break automation with older Chrome
 // builds..
-
+// Do label##PreStart so that automation messages keep the same id as before.
 #define IPC_BEGIN_MESSAGES(label) \
   enum label##MsgType { \
   label##Start = label##MsgStart << 12, \
-  label##PreStart = (label##MsgStart << 12) - 1,  // Do this so that automation messages keep the same id as before
+  label##PreStart = (label##MsgStart << 12) - 1,
 
 #define IPC_END_MESSAGES(label) \
   label##End \
   };
 
 #define IPC_MESSAGE_CONTROL0(msg_class) \
   msg_class##__ID,
 
 #define IPC_MESSAGE_CONTROL1(msg_class, type1) \
   msg_class##__ID,
@@ skipping 984 matching lines @@
    public: \
    enum { ID = msg_class##__ID }; \
     msg_class(int routing_id, const type1_in& arg1, const type2_in& arg2, const type3_in& arg3, const type4_in& arg4, type1_out* arg5, type2_out* arg6) \
         : IPC::MessageWithReply<Tuple4<type1_in, type2_in, type3_in, type4_in>, \
             Tuple2<type1_out&, type2_out&> >(routing_id, ID, \
             MakeTuple(arg1, arg2, arg3, arg4), MakeRefTuple(*arg5, *arg6)) {} \
   };
 
 #endif  // #if defined()