remove >> ambiguity in quic

remove >> ambiguity in quic_protocol.h

Resolve c++03 ambiguity introduced by CL 478153003 and 497553004, since 
we haven't officially switched over to c++11 yet.

Committed: https://crrev.com/dc40b8061f10dfd12aee6c51616393a1fa6a9e3e
Cr-Commit-Position: refs/heads/master@{#294094}

[Mostyn Bramley-Moore, 2014-09-09 21:09:16]

mostynb@opera.com changed reviewers:
+ rch@chromium.org, rtenneti@chromium.org

[Mostyn Bramley-Moore, 2014-09-09 21:12:02]

@Ryan: are you interested in taking this trivial patch, since we haven't (afaik)
officially switched over to c++11 yet?

[Ryan Hamilton, 2014-09-09 21:26:36]

looks good, modulo the line wrap.

https://codereview.chromium.org/561463002/diff/1/net/quic/quic_protocol.h
File net/quic/quic_protocol.h (right):

https://codereview.chromium.org/561463002/diff/1/net/quic/quic_protocol.h#new...
net/quic/quic_protocol.h:650: typedef
std::list<std::pair<QuicPacketSequenceNumber, QuicTime> > PacketTimeList;
nit: this line appears to be too long. I think you'll need to wrap.

[Mostyn Bramley-Moore, 2014-09-09 21:33:10]

https://codereview.chromium.org/561463002/diff/1/net/quic/quic_protocol.h
File net/quic/quic_protocol.h (right):

https://codereview.chromium.org/561463002/diff/1/net/quic/quic_protocol.h#new...
net/quic/quic_protocol.h:650: typedef
std::list<std::pair<QuicPacketSequenceNumber, QuicTime> > PacketTimeList;
On 2014/09/09 21:26:36, Ryan Hamilton wrote:
> nit: this line appears to be too long. I think you'll need to wrap.

Done.

[Ryan Hamilton, 2014-09-09 21:43:05]

lgtm

[Mostyn Bramley-Moore, 2014-09-09 21:43:57]

The CQ bit was checked by mostynb@opera.com

[commit-bot: I haz the power, 2014-09-09 22:06:33]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/mostynb@opera.com/561463002/20001

[Mostyn Bramley-Moore, 2014-09-09 23:20:11]

The CQ bit was unchecked by mostynb@opera.com

[Mostyn Bramley-Moore, 2014-09-09 23:24:15]

I spotted another instance of this in quic_received_packet_manager.h - can you
give this another thumbs-up?

[Ryan Hamilton, 2014-09-10 01:45:49]

The CQ bit was checked by rch@chromium.org

[Ryan Hamilton, 2014-09-10 01:45:49]

lgtm

[commit-bot: I haz the power, 2014-09-10 01:48:33]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/mostynb@opera.com/561463002/40001

[commit-bot: I haz the power, 2014-09-10 03:46:30]

Committed patchset #3 (id:40001) as 988bcfc093e6f4ed339168ec27f1464b1890db37

[commit-bot: I haz the power, 2014-09-10 03:58:51]

Patchset 3 (id:??) landed as
https://crrev.com/dc40b8061f10dfd12aee6c51616393a1fa6a9e3e
Cr-Commit-Position: refs/heads/master@{#294094}

[jamesr, 2014-09-10 05:46:51]

jamesr@chromium.org changed reviewers:
+ jamesr@chromium.org

[jamesr, 2014-09-10 05:46:52]

We use >> in templates extensively in Blink and have for a few years now.  There
are no toolchains we support that do not support this syntax.

[Mostyn Bramley-Moore, 2014-09-10 08:42:02]

On 2014/09/10 05:46:52, jamesr wrote:
> We use >> in templates extensively in Blink and have for a few years now. 
There
> are no toolchains we support that do not support this syntax.

I can't see any in instances of this type of ambiguity in the master branch in
third_party/WebKit/ - but perhaps my grep-foo is wrong?  The only hits I see are
for bit shifts or comments that refer to templates:
find third_party/WebKit/ -type f \( -name '*.cpp' -o -name '*.h' \) | xargs
fgrep $1 '>>'

[ramant (doing other things), 2014-09-10 10:51:01]

lgtm

Will be careful about ">>" while porting internal changes to chromium.