Improve loggging to debug invalid acks. No functional change.

Improve loggging to debug invalid acks.  No functional change.

Merge internal change: 113054959

R=rch@chromium.org

[ramant (doing other things), 2016-02-02 04:23:32]

Description was changed from

==========
Improve loggging to debug invalid acks.  No functional change.

Merge internal change: 113054959

R=rch@chromium.org
==========

to

==========
Improve loggging to debug invalid acks.  No functional change.

Merge internal change: 113054959

R=rch@chromium.org
==========

[Ryan Hamilton, 2016-02-02 04:33:19]

lgtm

https://codereview.chromium.org/1658923003/diff/1/net/quic/quic_connection.cc
File net/quic/quic_connection.cc (right):

https://codereview.chromium.org/1658923003/diff/1/net/quic/quic_connection.cc...
net/quic/quic_connection.cc:793: // clang-format off
Why clang-format off?

[ramant (doing other things), 2016-02-02 05:08:26]

https://codereview.chromium.org/1658923003/diff/1/net/quic/quic_connection.cc
File net/quic/quic_connection.cc (right):

https://codereview.chromium.org/1658923003/diff/1/net/quic/quic_connection.cc...
net/quic/quic_connection.cc:793: // clang-format off
On 2016/02/02 04:33:19, Ryan Hamilton wrote:
> Why clang-format off?

Added it to keep code in sync with internal code. Thought merging becomes easier
(internally LOG_FIRST_N and the intention to keep name: value on the same line
results in the following format). Chrome tries
to optimize for # of lines and formatting changes and results in conflicts. 

What do you think of using clang-format off/on to keep chromium code similar to
internal code.

    LOG_FIRST_N(WARNING, 10)
        << ENDPOINT
        << "Peer's observed unsent packet:" << incoming_ack.largest_observed
        << " vs " << packet_generator_.packet_number();

[Ryan Hamilton, 2016-02-02 05:23:26]

https://codereview.chromium.org/1658923003/diff/1/net/quic/quic_connection.cc
File net/quic/quic_connection.cc (right):

https://codereview.chromium.org/1658923003/diff/1/net/quic/quic_connection.cc...
net/quic/quic_connection.cc:793: // clang-format off
On 2016/02/02 05:08:25, ramant wrote:
> On 2016/02/02 04:33:19, Ryan Hamilton wrote:
> > Why clang-format off?
> 
> Added it to keep code in sync with internal code. Thought merging becomes
easier
> (internally LOG_FIRST_N and the intention to keep name: value on the same line
> results in the following format). Chrome tries
> to optimize for # of lines and formatting changes and results in conflicts. 
> 
> What do you think of using clang-format off/on to keep chromium code similar
to
> internal code.
> 
>     LOG_FIRST_N(WARNING, 10)
>         << ENDPOINT
>         << "Peer's observed unsent packet:" << incoming_ack.largest_observed
>         << " vs " << packet_generator_.packet_number();

Hm. I'm not in love with that. We could define LOG_FIRST_N if we wanted to?

[ramant (doing other things), 2016-02-02 06:42:10]

Reverted the clang-format statements. Thanks Ryan.

https://codereview.chromium.org/1658923003/diff/1/net/quic/quic_connection.cc
File net/quic/quic_connection.cc (right):

https://codereview.chromium.org/1658923003/diff/1/net/quic/quic_connection.cc...
net/quic/quic_connection.cc:793: // clang-format off
On 2016/02/02 05:23:26, Ryan Hamilton wrote:
> On 2016/02/02 05:08:25, ramant wrote:
> > On 2016/02/02 04:33:19, Ryan Hamilton wrote:
> > > Why clang-format off?
> > 
> > Added it to keep code in sync with internal code. Thought merging becomes
> easier
> > (internally LOG_FIRST_N and the intention to keep name: value on the same
line
> > results in the following format). Chrome tries
> > to optimize for # of lines and formatting changes and results in conflicts. 
> > 
> > What do you think of using clang-format off/on to keep chromium code similar
> to
> > internal code.
> > 
> >     LOG_FIRST_N(WARNING, 10)
> >         << ENDPOINT
> >         << "Peer's observed unsent packet:" << incoming_ack.largest_observed
> >         << " vs " << packet_generator_.packet_number();
> 
> Hm. I'm not in love with that. We could define LOG_FIRST_N if we wanted to?

Reverted the clang-format statements.

+1 to adding LOG_FIRST_N macro (will work on it in a separate CL).

[Ryan Hamilton, 2016-02-02 06:43:25]

On 2016/02/02 06:42:10, ramant wrote:
> Reverted the clang-format statements. Thanks Ryan.
> 
> https://codereview.chromium.org/1658923003/diff/1/net/quic/quic_connection.cc
> File net/quic/quic_connection.cc (right):
> 
>
https://codereview.chromium.org/1658923003/diff/1/net/quic/quic_connection.cc...
> net/quic/quic_connection.cc:793: // clang-format off
> On 2016/02/02 05:23:26, Ryan Hamilton wrote:
> > On 2016/02/02 05:08:25, ramant wrote:
> > > On 2016/02/02 04:33:19, Ryan Hamilton wrote:
> > > > Why clang-format off?
> > > 
> > > Added it to keep code in sync with internal code. Thought merging becomes
> > easier
> > > (internally LOG_FIRST_N and the intention to keep name: value on the same
> line
> > > results in the following format). Chrome tries
> > > to optimize for # of lines and formatting changes and results in
conflicts. 
> > > 
> > > What do you think of using clang-format off/on to keep chromium code
similar
> > to
> > > internal code.
> > > 
> > >     LOG_FIRST_N(WARNING, 10)
> > >         << ENDPOINT
> > >         << "Peer's observed unsent packet:" <<
incoming_ack.largest_observed
> > >         << " vs " << packet_generator_.packet_number();
> > 
> > Hm. I'm not in love with that. We could define LOG_FIRST_N if we wanted to?
> 
> Reverted the clang-format statements.
> 
> +1 to adding LOG_FIRST_N macro (will work on it in a separate CL).

Sounds good. I think it'd be fine to define it to simply be LOG_FIRST_N(level,
count) => LOG(level)