git cl format the second third of the net/base directory

git cl format the second third of the net/base directory

This is the first step in formatting the net/ directory.

How this CL was made: find . | egrep '(\.c|\.h|\.m|\.mm|\.cc|\.cp|\.cpp|\.c++|\.cxx|\.hpp|\.pro|\.protodevel|\.js)$' | tail -n 141 | head -n 70 | xargs clang-format --style=chromium -i

net/base/ CLs:
https://codereview.chromium.org/642403002/
* https://codereview.chromium.org/649763002/
https://codereview.chromium.org/647883002/

BUG=422332

[jkarlin, 2014-10-10 19:34:08]

jkarlin@chromium.org changed reviewers:
+ davidben@chromium.org

[jkarlin, 2014-10-10 19:34:51]

On 2014/10/10 19:34:08, jkarlin wrote:
> mailto:jkarlin@chromium.org changed reviewers:
> + mailto:davidben@chromium.org

Thanks David!

[davidben, 2014-10-10 20:24:17]

Thanks for doing this! I've left comments on things we may want to file bugs in
clang-format on. Common themes are:

1. Some array literals get noticeably off.

2. Really crazy macros confuse it. A few we can fix on our end to be
syntactically saner.

3. Line comments within an expression or literal sometimes confuse it. This
exacerbates 1.

4. Style question: are array literals indented two space or four space?
clang-format seems to think the latter, but google-c-style.el and most of our
code the former.

https://codereview.chromium.org/649763002/diff/1/net/base/address_tracker_lin...
File net/base/address_tracker_linux.cc (right):

https://codereview.chromium.org/649763002/diff/1/net/base/address_tracker_lin...
net/base/address_tracker_linux.cc:276: : MSG_DONTWAIT));
This looks like a clang-format bug.

https://codereview.chromium.org/649763002/diff/1/net/base/address_tracker_lin...
net/base/address_tracker_linux.cc:318: return;
Both of these seem pretty off. Move the return inside the block?

https://codereview.chromium.org/649763002/diff/1/net/base/bandwidth_metrics.h
File net/base/bandwidth_metrics.h (right):

https://codereview.chromium.org/649763002/diff/1/net/base/bandwidth_metrics.h...
net/base/bandwidth_metrics.h:93: << "Kbps)";
No action: I feel like the old one is slightly better because the parens match
up, but that's something clang-format is unlikely to learn and, personally, I
think being able to clang-format is more valuable.

https://codereview.chromium.org/649763002/diff/1/net/base/directory_lister_un...
File net/base/directory_lister_unittest.cc (right):

https://codereview.chromium.org/649763002/diff/1/net/base/directory_lister_un...
net/base/directory_lister_unittest.cc:48: for (size_t previous = 0, current = 1;
current < file_list_.size();
I feel like the old one here is slightly clearer, but don't particularly care.

https://codereview.chromium.org/649763002/diff/1/net/base/int128.h
File net/base/int128.h (right):

https://codereview.chromium.org/649763002/diff/1/net/base/int128.h#newcode145
net/base/int128.h:145: CMP128(<= )
This bit looks pretty bizarre but I don't think it's very important.

https://codereview.chromium.org/649763002/diff/1/net/base/int128.h#newcode179
net/base/int128.h:179: LOGIC128 (^)
The space after LOGIC128 is pretty bizarre too. That one might also be worth
filing a bug for.

https://codereview.chromium.org/649763002/diff/1/net/base/iovec.h
File net/base/iovec.h (right):

https://codereview.chromium.org/649763002/diff/1/net/base/iovec.h#newcode16
net/base/iovec.h:16: #endif  // defined(OS_LINUX)
Yikes, this file. Do you mind, probably in a separate CL:

1) Switch /* C-style */ comments to // C++-style. That'll probably also make it
get the indent on lines 13 and 14 right; I think they're supposed to be two
space.

2) Fix the comment on line 16 to say OS_POSIX

3) #include "build/build_config.h"

https://codereview.chromium.org/649763002/diff/1/net/base/load_timing_info_te...
File net/base/load_timing_info_test_util.h (right):

https://codereview.chromium.org/649763002/diff/1/net/base/load_timing_info_te...
net/base/load_timing_info_test_util.h:17: CONNECT_TIMING_HAS_SSL_TIMES = 1 << 1,
No action: loses some alignment, but I think either is fine.

https://codereview.chromium.org/649763002/diff/1/net/base/mime_sniffer.cc
File net/base/mime_sniffer.cc (right):

https://codereview.chromium.org/649763002/diff/1/net/base/mime_sniffer.cc#new...
net/base/mime_sniffer.cc:119: 
Okay, the tables in this file are pretty badly messed up. :-)

Here's an idea: remove the trailing comma from each of the macros and move them
to the array itself. That'll probably unconfuse clang-format. We could maybe
also file a bug under the "don't muck about with things you can't parse"
category, but I think the comma should be removed from the macros anyway.

https://codereview.chromium.org/649763002/diff/1/net/base/mime_sniffer.cc#new...
net/base/mime_sniffer.cc:681: 1, 1, 1, 1, 1, 1, 1, 1, 1, 0, 0, 1, 0, 0, 1, 1, 
// 0x00 - 0x0F
Is this a clang-format bug? google-c-style.el says this is two-space. Our
existing code seems to mostly do this two-space as well, though not uniformly. I
see some four-space in v8.

https://code.google.com/p/chromium/codesearch#search/&q=%5C%5B%5C%5D%5C%20=%5...

https://codereview.chromium.org/649763002/diff/1/net/base/mime_sniffer.cc#new...
net/base/mime_sniffer.cc:803: MAGIC_NUMBER("application/x-chrome-extension",
"Cr24\x02\x00\x00\x00")};
I feel like the newline between 776 and 777 should have stayed, but I don't care
strongly. I suspect doing the trailing comma thing will fix it though.

https://codereview.chromium.org/649763002/diff/1/net/base/mime_sniffer.cc#new...
net/base/mime_sniffer.cc:866:
"vnd.openxmlformats-officedocument.presentationml.presentation",
This is kind of unfortunate. Worth a clang-format bug to see if they could
indent line 866 some? Alternatively, if the two-space/four-space question above
is resolved in favor of two-space, I guess it wouldn't need to wrap this.

https://codereview.chromium.org/649763002/diff/1/net/base/mime_sniffer_unitte...
File net/base/mime_sniffer_unittest.cc (right):

https://codereview.chromium.org/649763002/diff/1/net/base/mime_sniffer_unitte...
net/base/mime_sniffer_unittest.cc:92: 1,
89 through 92 being on separate lines looks kinda funny. Dunno if we want a
clang-format bug? There's more instances of that in this file which are less
clear.

https://codereview.chromium.org/649763002/diff/1/net/base/mime_sniffer_unitte...
net/base/mime_sniffer_unittest.cc:107: SnifferTest tests[] = {// schemes
Probably worth a bug here too? Indenting all of these seems pretty silly.

https://codereview.chromium.org/649763002/diff/1/net/base/net_util_unittest.cc
File net/base/net_util_unittest.cc (right):

https://codereview.chromium.org/649763002/diff/1/net/base/net_util_unittest.c...
net/base/net_util_unittest.cc:238: {"foo:10", true, "foo", 10},
This looks worth a bug. I think it overlaps with an earlier instance? It seems
to get confused with line-comments within an array literal.

https://codereview.chromium.org/649763002/diff/1/net/base/net_util_unittest.c...
net/base/net_util_unittest.cc:384: "fedc:ba98:7654:3210:fedc:ba98:7654:3210"},
This block also looks bizarrely indented.

https://codereview.chromium.org/649763002/diff/1/net/base/net_util_unittest.c...
net/base/net_util_unittest.cc:420: 0x10};
Might also be worth a bug to get this on one line?

https://codereview.chromium.org/649763002/diff/1/net/base/net_util_unittest.c...
net/base/net_util_unittest.cc:444: {// Reference section should be stripped.
Array literal with line comment again.

https://codereview.chromium.org/649763002/diff/1/net/base/net_util_unittest.c...
net/base/net_util_unittest.cc:650: {"10.10.1.32/27", "10.10.1.90", false},
Array literal with line comment again.

https://codereview.chromium.org/649763002/diff/1/net/base/net_util_unittest.c...
net/base/net_util_unittest.cc:963: INSTANTIATE_TEST_CASE_P(,
No action: I think this is going to look weird no matter how we indent it...
what is up with this first argument? :-)

https://codereview.chromium.org/649763002/diff/1/net/base/network_change_noti...
File net/base/network_change_notifier.cc (right):

https://codereview.chromium.org/649763002/diff/1/net/base/network_change_noti...
net/base/network_change_notifier.cc:560: "CONNECTION_BLUETOOTH"};
This is probably also better as before, but no strong opinion.

https://codereview.chromium.org/649763002/diff/1/net/base/network_change_noti...
net/base/network_change_notifier.cc:743: /*= NetworkChangeCalculatorParams()*/)
This comment should probably have stayed indented, but I don't know if we care
enough. It's an awfully specific comment to teach clang-format to recognize and
I don't see that many instances in codesearch.

https://codereview.chromium.org/649763002/diff/1/net/base/trace_net_log_obser...
File net/base/trace_net_log_observer.cc (right):

https://codereview.chromium.org/649763002/diff/1/net/base/trace_net_log_obser...
net/base/trace_net_log_observer.cc:64:
scoped_refptr<base::debug::ConvertableToTraceFormat>(
No action: The old one is a little better for this macro (last few arguments
come in pairs), but there's no way we'll teach clang-format it and I personally
think clang-format is worth it.

[jkarlin, 2014-10-31 00:46:30]

https://codereview.chromium.org/649763002/diff/1/net/base/int128.h
File net/base/int128.h (right):

https://codereview.chromium.org/649763002/diff/1/net/base/int128.h#newcode179
net/base/int128.h:179: LOGIC128 (^)
On 2014/10/10 20:24:15, David Benjamin wrote:
> The space after LOGIC128 is pretty bizarre too. That one might also be worth
> filing a bug for.

Filed https://code.google.com/p/chromium/issues/detail?id=429032

https://codereview.chromium.org/649763002/diff/1/net/base/mime_sniffer_unitte...
File net/base/mime_sniffer_unittest.cc (right):

https://codereview.chromium.org/649763002/diff/1/net/base/mime_sniffer_unitte...
net/base/mime_sniffer_unittest.cc:92: 1,
On 2014/10/10 20:24:16, David Benjamin wrote:
> 89 through 92 being on separate lines looks kinda funny. Dunno if we want a
> clang-format bug? There's more instances of that in this file which are less
> clear.

Filed https://code.google.com/p/chromium/issues/detail?id=429045

[jkarlin, 2014-10-31 15:55:14]

My plan is to wait for the next clang-format roll, then I'll rebase, make
reasonable fixes by hand, reformat, and ask you to take another look.

https://codereview.chromium.org/649763002/diff/1/net/base/mime_sniffer_unitte...
File net/base/mime_sniffer_unittest.cc (right):

https://codereview.chromium.org/649763002/diff/1/net/base/mime_sniffer_unitte...
net/base/mime_sniffer_unittest.cc:92: 1,
On 2014/10/31 00:46:30, jkarlin wrote:
> On 2014/10/10 20:24:16, David Benjamin wrote:
> > 89 through 92 being on separate lines looks kinda funny. Dunno if we want a
> > clang-format bug? There's more instances of that in this file which are less
> > clear.
> 
> Filed https://code.google.com/p/chromium/issues/detail?id=429045

Bug resolution is to just merge the two string literals, there is no reason for
them to be separate.  clang-format assumes that two adjacent string literals are
meant to be on separate lines.

[jkarlin, 2014-12-18 18:29:29]

Closing as this is now out of date and we don't have immediate plans to format
all of net/