Fix a few typos in the IPC message macros documentation

ipc/ipc_message_macros.h

 // Copyright (c) 2012 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.
 
 // Defining IPC Messages
 //
 // Your IPC messages will be defined by macros inside of an XXX_messages.h
 // header file.  Most of the time, the system can automatically generate all
 // of messaging mechanism from these definitions, but sometimes some manual
 // coding is required.  In these cases, you will also have an XXX_messages.cc
-// implemation file as well.
+// implementation file as well.
 //
 // The senders of your messages will include your XXX_messages.h file to
 // get the full set of definitions they need to send your messages.
 //
 // Each XXX_messages.h file must be registered with the IPC system.  This
 // requires adding two things:
 //   - An XXXMsgStart value to the IPCMessageStart enum in ipc_message_start.h
 //   - An inclusion of XXX_messages.h file in a message generator .h file
 //
 // The XXXMsgStart value is an enumeration that ensures uniqueness for
 // each different message file.  Later, you will use this inside your
 // XXX_messages.h file before invoking message declaration macros:
 //     #define IPC_MESSAGE_START XXXMsgStart
 //       ( ... your macro invocations go here ... )
 //
 // Message Generator Files
 //
 // A message generator .h header file pulls in all other message-declaring
 // headers for a given component.  It is included by a message generator
 // .cc file, which is where all the generated code will wind up.  Typically,
 // you will use an existing generator (e.g. common_message_generator.cc
 // in /chrome/common), but there are circumstances where you may add a
 // new one.
 //
-// In the rare cicrucmstances where you can't re-use an existing file,
+// In the rare circumstances where you can't re-use an existing file,
 // your YYY_message_generator.cc file for a component YYY would contain
 // the following code:
 //     // Get basic type definitions.
 //     #define IPC_MESSAGE_IMPL
 //     #include "path/to/YYY_message_generator.h"
 //     // Generate constructors.
 //     #include "ipc/struct_constructor_macros.h"
 //     #include "path/to/YYY_message_generator.h"
 //     // Generate destructors.
 //     #include "ipc/struct_destructor_macros.h"
@@ skipping 18 matching lines @@
 // file, put the following after all the includes for param types:
 //     #define IPC_MESSAGE_IMPL
 //     #include "XXX_messages.h"
 //        (... implementation of traits not auto-generated ...)
 //
 // Multiple Inclusion
 //
 // The XXX_messages.h file will be multiply-included by the
 // YYY_message_generator.cc file, so your XXX_messages file can't be
 // guarded in the usual manner.  Ideally, there will be no need for any
-// inclusion guard, since the XXX_messages.h file should consist soley
+// inclusion guard, since the XXX_messages.h file should consist solely
 // of inclusions of other headers (which are self-guarding) and IPC
 // macros (which are multiply evaluating).
 //
 // Note that #pragma once cannot be used here; doing so would mark the whole
 // file as being singly-included.  Since your XXX_messages.h file is only
 // partially-guarded, care must be taken to ensure that it is only included
 // by other .cc files (and the YYY_message_generator.h file).  Including an
 // XXX_messages.h file in some other .h file may result in duplicate
 // declarations and a compilation failure.
 //
 // Type Declarations
 //
 // It is generally a bad idea to have type definitions in a XXX_messages.h
 // file; most likely the typedef will then be used in the message, as opposed
-// to the struct iself.  Later, an IPC message dispatcher wil need to call
+// to the struct itself.  Later, an IPC message dispatcher will need to call
 // a function taking that type, and that function is declared in some other
 // header.  Thus, in order to get the type definition, the other header
 // would have to include the XXX_messages.h file, violating the rule above
 // about not including XXX_messages.h file in other .h files.
 //
 // One approach here is to move these type definitions to another (guarded)
 // .h file and include this second .h in your XXX_messages.h file.  This
 // is still less than ideal, because the dispatched function would have to
 // redeclare the typedef or include this second header.  This may be
 // reasonable in a few cases.
 //
 // Failing all of the above, then you will want to bracket the smallest
 // possible section of your XXX_messages.h file containing these types
 // with an include guard macro.  Be aware that providing an incomplete
 // class type declaration to avoid pulling in a long chain of headers is
 // acceptable when your XXX_messages.h header is being included by the
 // message sending caller's code, but not when the YYY_message_generator.c
-// is building the messages. In addtion, due to the multiple inclusion
+// is building the messages. In addition, due to the multiple inclusion
 // restriction, these type ought to be guarded.  Follow a convention like:
 //      #ifndef SOME_GUARD_MACRO
 //      #define SOME_GUARD_MACRO
 //      class some_class;        // One incomplete class declaration
 //      class_some_other_class;  // Another incomplete class declaration
 //      #endif  // SOME_GUARD_MACRO
 //      #ifdef IPC_MESSAGE_IMPL
 //      #include "path/to/some_class.h"        // Full class declaration
 //      #include "path/to/some_other_class.h"  // Full class declaration
 //      #endif  // IPC_MESSAGE_IMPL
 //        (.. IPC macros using some_class and some_other_class ...)
 //
 // Macro Invocations
 //
 // You will use IPC message macro invocations for three things:
 //   - New struct definitions for IPC
 //   - Registering existing struct and enum definitions with IPC
 //   - Defining the messages themselves
 //
 // New structs are defined with IPC_STRUCT_BEGIN(), IPC_STRUCT_MEMBER(),
 // IPC_STRUCT_END() family of macros.  These cause the XXX_messages.h
 // to proclaim equivalent struct declarations for use by callers, as well
 // as later registering the type with the message generation.  Note that
 // IPC_STRUCT_MEMBER() is only permitted inside matching calls to
 // IPC_STRUCT_BEGIN() / IPC_STRUCT_END(). There is also an
 // IPC_STRUCT_BEGIN_WITH_PARENT(), which behaves like IPC_STRUCT_BEGIN(),
-// but also accomodates structs that inherit from other structs.
+// but also accommodates structs that inherit from other structs.
 //
 // Externally-defined structs are registered with IPC_STRUCT_TRAITS_BEGIN(),
 // IPC_STRUCT_TRAITS_MEMBER(), and IPC_STRUCT_TRAITS_END() macros. These
 // cause registration of the types with message generation only.
 // There's also IPC_STRUCT_TRAITS_PARENT, which is used to register a parent
 // class (whose own traits are already defined). Note that
 // IPC_STRUCT_TRAITS_MEMBER() and IPC_STRUCT_TRAITS_PARENT are only permitted
 // inside matching calls to IPC_STRUCT_TRAITS_BEGIN() /
 // IPC_STRUCT_TRAITS_END().
 //
@@ skipping 827 matching lines @@
 // This corresponds to an enum value from IPCMessageStart.
 #define IPC_MESSAGE_CLASS(message) \
   IPC_MESSAGE_ID_CLASS(message.type())
 
 #endif  // IPC_IPC_MESSAGE_MACROS_H_
 
 // Clean up IPC_MESSAGE_START in this unguarded section so that the
 // XXX_messages.h files need not do so themselves.  This makes the
 // XXX_messages.h files easier to write.
 #undef IPC_MESSAGE_START