Add IPC and Windows message map macro blocks to .clang-format options

Add IPC and Windows message map macro blocks to .clang-format options

Use the new MacroBlockBegin/MacroBlockEnd options introduced in
http://reviews.llvm.org/rL241363 so clang-format can correctly indent
the bodies of IPC message maps, etc.

BUG=373340
R=thakis@chromium.org
TBR=darin@chromium.org

Committed: https://chromium.googlesource.com/chromium/src/+/9ce8be44d36f1d8e52a571a18def3b5295cf0763

[dcheng, 2015-07-16 21:24:42]

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

[dcheng, 2015-07-16 21:24:42]

Yay, clang-format.

[Nico, 2015-07-16 21:26:47]

Is there some way of formatting this that we don't have to put all of them on a
single line?

Can you format some sample ipc macro line and include that in this cl as demo?

[Nico, 2015-07-16 21:28:27]

https://codereview.chromium.org/1225333004/diff/1/.clang-format
File .clang-format (right):

https://codereview.chromium.org/1225333004/diff/1/.clang-format#newcode9
.clang-format:9: MacroBlockBegin:
^BEGIN_SAFE_MSG_MAP_EX|CR_BEGIN_MSG_MAP_EX|IPC_BEGIN_MESSAGE_MAP|IPC_BEGIN_MESSAGE_MAP_WITH_PARAM|IPC_STRUCT_BEGIN|IPC_STRUCT_BEGIN_WITH_PARENT|IPC_STRUCT_TRAITS_BEGIN$
what about regular BEGIN_MSG_MAP_EX? all the mfc/atl-y message routing macros?

[dcheng, 2015-07-16 21:35:26]

On 2015/07/16 at 21:26:47, thakis wrote:
> Is there some way of formatting this that we don't have to put all of them on
a single line?
> 

Done.

> Can you format some sample ipc macro line and include that in this cl as demo?

I hope I interpreted this correctly.

[dcheng, 2015-07-16 21:38:04]

On 2015/07/16 at 21:28:27, thakis wrote:
> https://codereview.chromium.org/1225333004/diff/1/.clang-format
> File .clang-format (right):
> 
> https://codereview.chromium.org/1225333004/diff/1/.clang-format#newcode9
> .clang-format:9: MacroBlockBegin:
^BEGIN_SAFE_MSG_MAP_EX|CR_BEGIN_MSG_MAP_EX|IPC_BEGIN_MESSAGE_MAP|IPC_BEGIN_MESSAGE_MAP_WITH_PARAM|IPC_STRUCT_BEGIN|IPC_STRUCT_BEGIN_WITH_PARENT|IPC_STRUCT_TRAITS_BEGIN$
> what about regular BEGIN_MSG_MAP_EX? all the mfc/atl-y message routing macros?

I thought these weren't used, but I was wrong. Not familiar with the MFC ones (I
don't think we use MFC, and we only have very minimal dependencies on ATL,
AFAIK)

[Nico, 2015-07-16 21:38:27]

Nice, thanks!

Did you see the "what about regular BEGIN_MSG_MAP_EX? all the mfc/atl-y message
routing macros?" question? BEGIN_MSG_MAP_EX at least is similar to
SAFE_BEGIN_MSG_MAP_EX. And SAFE_BEGIN_MSG_MAP_EX goes with the regular
END_MSG_MAP() I think.

What's our bar for adding stuff to these lists? Probably not for macros only
used in one file?

[dcheng, 2015-07-16 21:41:15]

On 2015/07/16 at 21:38:27, thakis wrote:
> Nice, thanks!
> 
> Did you see the "what about regular BEGIN_MSG_MAP_EX? all the mfc/atl-y
message routing macros?" question? BEGIN_MSG_MAP_EX at least is similar to
SAFE_BEGIN_MSG_MAP_EX. And SAFE_BEGIN_MSG_MAP_EX goes with the regular
END_MSG_MAP() I think.
> 
> What's our bar for adding stuff to these lists? Probably not for macros only
used in one file?

In this particular case, BEGIN_MSG_MAP is used in one file and BEGIN_MSG_MAP_EX
is used in 2. But it doesn't really make sense (IMO) to have one without the
other, so I just added both.

I guess it's OK to add macros with relatively little usage if they're "system"
macros. For macros that people want to define, I guess we should encourage them
to first find a non-macro solution if possible =P

[Nico, 2015-07-16 21:43:03]

makes sense. lgtm, thanks!

[dcheng, 2015-07-16 21:44:41]

TBRing darin@ for OWNERS approval in /

[dcheng, 2015-07-16 21:47:04]

Committed patchset #3 (id:40001) manually as
9ce8be44d36f1d8e52a571a18def3b5295cf0763 (presubmit successful).