Make operators on scoped_ptr match the ones defined for std::unique_ptr

Make operators on scoped_ptr match the ones defined for std::unique_ptr

Currently scoped_ptr is missing comparison operators other than == and
!=, and it defines those operators incorrectly (it compares to a raw
pointer but unique_ptr compares to a unique_ptr).

This fixes the operator== and !=, and adds .get() at a bunch of
callsites. And adds the < > <= >= operators so that we don't have any
differences in where you can use it. This will help the transition
from scoped_ptr to unique_ptr as no code will have to change along with
the rename wrt these operators.

R=Nico, dcheng
TBR=ellyjones, sky, jochen, wez, rockot, droger
BUG=554390
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel

Committed: https://crrev.com/8199479504103bee23b5e560a96b914b9d959caf
Cr-Commit-Position: refs/heads/master@{#359957}

[danakj, 2015-11-11 20:38:36]

https://codereview.chromium.org/1440593004/diff/1/base/memory/scoped_ptr.h
File base/memory/scoped_ptr.h (right):

https://codereview.chromium.org/1440593004/diff/1/base/memory/scoped_ptr.h#ne...
base/memory/scoped_ptr.h:538: template <class T1, class D1, class T2, class D2>
Here are the libcxx implementations of these operators:
https://github.com/llvm-mirror/libcxx/blob/master/include/memory#L2981

These are the same with 2 differences:
- I used ptr < ptr instead of std::less(ptr, ptr) cuz that's c++14.
- I used !!p instead of static_cast<bool>(p). unique_ptr has operator bool but
we don't on scoped_ptr.

Otherwise they should be 1:1 the same exact code.

[danakj, 2015-11-11 20:43:27]

Description was changed from

==========
Make operators on scoped_ptr match the ones defined for std::unique_ptr

Currently scoped_ptr is missing comparison operators other than == and
!=, and it defines those operators incorrectly (it compares to a raw
pointer but unique_ptr compares to a unique_ptr).

This fixes the operator== and !=, and adds .get() at a bunch of
callsites. And adds the < > <= >= operators so that we don't have any
differences in where you can use it. This will help the transition
from scoped_ptr to unique_ptr as no code will have to change along with
the rename wrt these operators.

R=Nico, dcheng
BUG=554390
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel
==========

to

==========
Make operators on scoped_ptr match the ones defined for std::unique_ptr

Currently scoped_ptr is missing comparison operators other than == and
!=, and it defines those operators incorrectly (it compares to a raw
pointer but unique_ptr compares to a unique_ptr).

This fixes the operator== and !=, and adds .get() at a bunch of
callsites. And adds the < > <= >= operators so that we don't have any
differences in where you can use it. This will help the transition
from scoped_ptr to unique_ptr as no code will have to change along with
the rename wrt these operators.

R=Nico, dcheng
BUG=554390
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel
==========

[danakj, 2015-11-11 20:45:06]

danakj@chromium.org changed reviewers:
+ ellyjones@chromium.org, jochen@chromium.org, sky@chromium.org

[danakj, 2015-11-11 20:45:36]

danakj@chromium.org changed reviewers:
+ wez@chromium.org

[danakj, 2015-11-11 20:46:01]

Description was changed from

==========
Make operators on scoped_ptr match the ones defined for std::unique_ptr

Currently scoped_ptr is missing comparison operators other than == and
!=, and it defines those operators incorrectly (it compares to a raw
pointer but unique_ptr compares to a unique_ptr).

This fixes the operator== and !=, and adds .get() at a bunch of
callsites. And adds the < > <= >= operators so that we don't have any
differences in where you can use it. This will help the transition
from scoped_ptr to unique_ptr as no code will have to change along with
the rename wrt these operators.

R=Nico, dcheng
BUG=554390
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel
==========

to

==========
Make operators on scoped_ptr match the ones defined for std::unique_ptr

Currently scoped_ptr is missing comparison operators other than == and
!=, and it defines those operators incorrectly (it compares to a raw
pointer but unique_ptr compares to a unique_ptr).

This fixes the operator== and !=, and adds .get() at a bunch of
callsites. And adds the < > <= >= operators so that we don't have any
differences in where you can use it. This will help the transition
from scoped_ptr to unique_ptr as no code will have to change along with
the rename wrt these operators.

R=Nico, dcheng
TBR=ellyjones, sky, jochen, wez
BUG=554390
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel
==========

[danakj, 2015-11-11 20:47:29]

Patchset #2 (id:20001) has been deleted

[dcheng, 2015-11-11 20:55:06]

dcheng@chromium.org changed reviewers:
- ellyjones@chromium.org, jochen@chromium.org, sky@chromium.org,
wez@chromium.org

[dcheng, 2015-11-11 20:55:07]

https://codereview.chromium.org/1440593004/diff/1/base/memory/scoped_ptr.h
File base/memory/scoped_ptr.h (right):

https://codereview.chromium.org/1440593004/diff/1/base/memory/scoped_ptr.h#ne...
base/memory/scoped_ptr.h:579: return p1.get() > p2.get();
Not necessary, but it can be nice to express these operators in terms of
previously defined ones. So this would read:

  return p2 < p1;

etc for the others.

The rationale for this is to make it harder to write bugs where complementary
operators like == and != are both true or both false for a given p1 and p2, etc.

[danakj, 2015-11-11 21:01:16]

PTAL

https://codereview.chromium.org/1440593004/diff/1/base/memory/scoped_ptr.h
File base/memory/scoped_ptr.h (right):

https://codereview.chromium.org/1440593004/diff/1/base/memory/scoped_ptr.h#ne...
base/memory/scoped_ptr.h:579: return p1.get() > p2.get();
On 2015/11/11 20:55:06, dcheng wrote:
> Not necessary, but it can be nice to express these operators in terms of
> previously defined ones. So this would read:
> 
>   return p2 < p1;
> 
> etc for the others.
> 
> The rationale for this is to make it harder to write bugs where complementary
> operators like == and != are both true or both false for a given p1 and p2,
etc.

yup good idea. done. also wrote a bug and realized tests could be improved which
i did.

[dcheng, 2015-11-11 22:01:04]

https://codereview.chromium.org/1440593004/diff/60001/base/memory/scoped_ptr.h
File base/memory/scoped_ptr.h (right):

https://codereview.chromium.org/1440593004/diff/60001/base/memory/scoped_ptr....
base/memory/scoped_ptr.h:579: return p2.get() < p1.get();
Sorry, to clarify:
Right now, operator!=(scoped_ptr, scoped_ptr) simply calls
operator==(scoped_ptr, scoped_ptr). I think operator> should do the same, so no
.get() is needed here or the nullptr_t overloads, and likewise for operator<=
and operator >=.

[danakj, 2015-11-11 23:32:45]

https://codereview.chromium.org/1440593004/diff/60001/base/memory/scoped_ptr.h
File base/memory/scoped_ptr.h (right):

https://codereview.chromium.org/1440593004/diff/60001/base/memory/scoped_ptr....
base/memory/scoped_ptr.h:579: return p2.get() < p1.get();
On 2015/11/11 22:01:04, dcheng wrote:
> Sorry, to clarify:
> Right now, operator!=(scoped_ptr, scoped_ptr) simply calls
> operator==(scoped_ptr, scoped_ptr). I think operator> should do the same, so
no
> .get() is needed here or the nullptr_t overloads, and likewise for operator<=
> and operator >=.

err.. ya. thats what i meant to do oops.  thanks for the careful review.

[danakj, 2015-11-12 00:26:57]

PTAL

[danakj, 2015-11-12 00:29:34]

danakj@chromium.org changed reviewers:
+ ellyjones@chromium.org, jochen@chromium.org, sky@chromium.org,
wez@chromium.org

[danakj, 2015-11-12 00:30:25]

Description was changed from

==========
Make operators on scoped_ptr match the ones defined for std::unique_ptr

Currently scoped_ptr is missing comparison operators other than == and
!=, and it defines those operators incorrectly (it compares to a raw
pointer but unique_ptr compares to a unique_ptr).

This fixes the operator== and !=, and adds .get() at a bunch of
callsites. And adds the < > <= >= operators so that we don't have any
differences in where you can use it. This will help the transition
from scoped_ptr to unique_ptr as no code will have to change along with
the rename wrt these operators.

R=Nico, dcheng
TBR=ellyjones, sky, jochen, wez
BUG=554390
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel
==========

to

==========
Make operators on scoped_ptr match the ones defined for std::unique_ptr

Currently scoped_ptr is missing comparison operators other than == and
!=, and it defines those operators incorrectly (it compares to a raw
pointer but unique_ptr compares to a unique_ptr).

This fixes the operator== and !=, and adds .get() at a bunch of
callsites. And adds the < > <= >= operators so that we don't have any
differences in where you can use it. This will help the transition
from scoped_ptr to unique_ptr as no code will have to change along with
the rename wrt these operators.

R=Nico, dcheng
TBR=ellyjones, sky, jochen, wez, rockot, droger
BUG=554390
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel
==========

[danakj, 2015-11-12 00:30:25]

danakj@chromium.org changed reviewers:
+ droger@chromium.org, rockot@chromium.org

[dcheng, 2015-11-12 16:17:04]

https://codereview.chromium.org/1440593004/diff/100001/base/memory/scoped_ptr.h
File base/memory/scoped_ptr.h (right):

https://codereview.chromium.org/1440593004/diff/100001/base/memory/scoped_ptr...
base/memory/scoped_ptr.h:328: scoped_ptr(std::nullptr_t n) : impl_(nullptr) {}
Apparently the style rule around naming parameters changed this year (see
b/19617501 for the details).
http://google.github.io/styleguide/cppguide.html#Function_Declarations_and_De...
now says:

  Parameter names may be omitted only if the parameter is unused and its purpose
is obvious.

So I think we should omit the name here and elsewhere. I don't see any specific
rules in the Chromium style about this (nor do I think we should add any).

[Nico, 2015-11-12 17:20:47]

Lgtm from me. Not having parameter names for nullptr_t args makes sense to me

https://codereview.chromium.org/1440593004/diff/100001/base/memory/scoped_ptr.h
File base/memory/scoped_ptr.h (right):

https://codereview.chromium.org/1440593004/diff/100001/base/memory/scoped_ptr...
base/memory/scoped_ptr.h:544: return !p;
nit: i'd say `return p.get() == nullptr` (and for != `get() != nullptr` instead
of !!) – like you do with op< etc

[danakj, 2015-11-13 22:19:41]

https://codereview.chromium.org/1440593004/diff/100001/base/memory/scoped_ptr.h
File base/memory/scoped_ptr.h (right):

https://codereview.chromium.org/1440593004/diff/100001/base/memory/scoped_ptr...
base/memory/scoped_ptr.h:328: scoped_ptr(std::nullptr_t n) : impl_(nullptr) {}
On 2015/11/12 16:17:03, dcheng wrote:
> Apparently the style rule around naming parameters changed this year (see
> b/19617501 for the details).
>
http://google.github.io/styleguide/cppguide.html#Function_Declarations_and_De...
> now says:
> 
>   Parameter names may be omitted only if the parameter is unused and its
purpose
> is obvious.
> 
> So I think we should omit the name here and elsewhere. I don't see any
specific
> rules in the Chromium style about this (nor do I think we should add any).

Done.

https://codereview.chromium.org/1440593004/diff/100001/base/memory/scoped_ptr...
base/memory/scoped_ptr.h:544: return !p;
On 2015/11/12 17:20:47, Nico wrote:
> nit: i'd say `return p.get() == nullptr` (and for != `get() != nullptr`
instead
> of !!) –&nbsp;like you do with op< etc

Done. Used .get() == nullptr here, and below I did

!(p == nullptr)

to just reuse the == operator, if we're not going to try match how libc++
happened to write it super closely.

[danakj, 2015-11-13 22:20:46]

On Thu, Nov 12, 2015 at 8:17 AM, <dcheng@chromium.org> wrote:

>
>
>
https://codereview.chromium.org/1440593004/diff/100001/base/memory/scoped_ptr.h
> File base/memory/scoped_ptr.h (right):
>
>
>
https://codereview.chromium.org/1440593004/diff/100001/base/memory/scoped_ptr...
> base/memory/scoped_ptr.h:328: scoped_ptr(std::nullptr_t n) :
> impl_(nullptr) {}
> Apparently the style rule around naming parameters changed this year
> (see b/19617501 <https://buganizer.corp.google.com/19617501> for the
> details).
>
>
http://google.github.io/styleguide/cppguide.html#Function_Declarations_and_De...
> now says:
>
>   Parameter names may be omitted only if the parameter is unused and its
> purpose is obvious.
>

omg that is so exciting. thank you for pointing that out. will happily do
that.


>
> So I think we should omit the name here and elsewhere. I don't see any
> specific rules in the Chromium style about this (nor do I think we
> should add any).
>
> https://codereview.chromium.org/1440593004/
>

-- 
You received this message because you are subscribed to the Google Groups
"Chromium-reviews" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[danakj, 2015-11-13 22:21:55]

PTAL

[dcheng, 2015-11-13 22:25:55]

lgtm

https://codereview.chromium.org/1440593004/diff/100001/base/memory/scoped_ptr.h
File base/memory/scoped_ptr.h (right):

https://codereview.chromium.org/1440593004/diff/100001/base/memory/scoped_ptr...
base/memory/scoped_ptr.h:328: scoped_ptr(std::nullptr_t n) : impl_(nullptr) {}
On 2015/11/12 at 16:17:03, dcheng wrote:
> Apparently the style rule around naming parameters changed this year (see
b/19617501 for the details).
http://google.github.io/styleguide/cppguide.html#Function_Declarations_and_De...
now says:
> 
>   Parameter names may be omitted only if the parameter is unused and its
purpose is obvious.
> 
> So I think we should omit the name here and elsewhere. I don't see any
specific rules in the Chromium style about this (nor do I think we should add
any).

Another random thing I just thought of: should we prefer to include cstddef
instead of stddef.h for nullptr_t?

[danakj, 2015-11-13 22:35:23]

https://codereview.chromium.org/1440593004/diff/100001/base/memory/scoped_ptr.h
File base/memory/scoped_ptr.h (right):

https://codereview.chromium.org/1440593004/diff/100001/base/memory/scoped_ptr...
base/memory/scoped_ptr.h:328: scoped_ptr(std::nullptr_t n) : impl_(nullptr) {}
On 2015/11/13 22:25:55, dcheng wrote:
> On 2015/11/12 at 16:17:03, dcheng wrote:
> > Apparently the style rule around naming parameters changed this year (see
> b/19617501 for the details).
>
http://google.github.io/styleguide/cppguide.html#Function_Declarations_and_De...
> now says:
> > 
> >   Parameter names may be omitted only if the parameter is unused and its
> purpose is obvious.
> > 
> > So I think we should omit the name here and elsewhere. I don't see any
> specific rules in the Chromium style about this (nor do I think we should add
> any).
> 
> Another random thing I just thought of: should we prefer to include cstddef
> instead of stddef.h for nullptr_t?

I don't think stddef.h does the right thing (it doesn't put it in std::?) I
tried to use it in another CL and it was bad but cstddef worked).

I guess this file already includes stddef.h, but it must end up getting
std::nullptr_t from somewhere else?

[dcheng, 2015-11-13 22:41:03]

On 2015/11/13 at 22:35:23, danakj wrote:
>
https://codereview.chromium.org/1440593004/diff/100001/base/memory/scoped_ptr.h
> File base/memory/scoped_ptr.h (right):
> 
>
https://codereview.chromium.org/1440593004/diff/100001/base/memory/scoped_ptr...
> base/memory/scoped_ptr.h:328: scoped_ptr(std::nullptr_t n) : impl_(nullptr) {}
> On 2015/11/13 22:25:55, dcheng wrote:
> > On 2015/11/12 at 16:17:03, dcheng wrote:
> > > Apparently the style rule around naming parameters changed this year (see
> > b/19617501 for the details).
> >
http://google.github.io/styleguide/cppguide.html#Function_Declarations_and_De...
> > now says:
> > > 
> > >   Parameter names may be omitted only if the parameter is unused and its
> > purpose is obvious.
> > > 
> > > So I think we should omit the name here and elsewhere. I don't see any
> > specific rules in the Chromium style about this (nor do I think we should
add
> > any).
> > 
> > Another random thing I just thought of: should we prefer to include cstddef
> > instead of stddef.h for nullptr_t?
> 
> I don't think stddef.h does the right thing (it doesn't put it in std::?) I
tried to use it in another CL and it was bad but cstddef worked).
> 
> I guess this file already includes stddef.h, but it must end up getting
std::nullptr_t from somewhere else?

Sorry I meant to delete this draft comment before replying, but since the
discussion started... if the codebase universally included cstddef instead of
stddef.h, doesn't that mean we'd have to qualify things like size_t with std::
too? That seems undesirable. So I don't really know what the answer is.

[danakj, 2015-11-13 22:45:00]

On 2015/11/13 22:41:03, dcheng wrote:
> On 2015/11/13 at 22:35:23, danakj wrote:
> >
>
https://codereview.chromium.org/1440593004/diff/100001/base/memory/scoped_ptr.h
> > File base/memory/scoped_ptr.h (right):
> > 
> >
>
https://codereview.chromium.org/1440593004/diff/100001/base/memory/scoped_ptr...
> > base/memory/scoped_ptr.h:328: scoped_ptr(std::nullptr_t n) : impl_(nullptr)
{}
> > On 2015/11/13 22:25:55, dcheng wrote:
> > > On 2015/11/12 at 16:17:03, dcheng wrote:
> > > > Apparently the style rule around naming parameters changed this year
(see
> > > b/19617501 for the details).
> > >
>
http://google.github.io/styleguide/cppguide.html#Function_Declarations_and_De...
> > > now says:
> > > > 
> > > >   Parameter names may be omitted only if the parameter is unused and its
> > > purpose is obvious.
> > > > 
> > > > So I think we should omit the name here and elsewhere. I don't see any
> > > specific rules in the Chromium style about this (nor do I think we should
> add
> > > any).
> > > 
> > > Another random thing I just thought of: should we prefer to include
cstddef
> > > instead of stddef.h for nullptr_t?
> > 
> > I don't think stddef.h does the right thing (it doesn't put it in std::?) I
> tried to use it in another CL and it was bad but cstddef worked).
> > 
> > I guess this file already includes stddef.h, but it must end up getting
> std::nullptr_t from somewhere else?
> 
> Sorry I meant to delete this draft comment before replying, but since the
> discussion started... if the codebase universally included cstddef instead of
> stddef.h, doesn't that mean we'd have to qualify things like size_t with std::
> too? That seems undesirable. So I don't really know what the answer is.

Maybe we just include stddef.h for size_t and cstddef for nullptr, and write
nullptr_t as std:: always. It's inconsistent but consistent? <___<

It's easy enough to presubmit check people are writing std:: on nullptr_t, for
example (and even that they aren't on size_t). Helping people understand why
they need both headers might be weird. Meeehhhh.

[danakj, 2015-11-13 22:45:29]

The CQ bit was checked by danakj@chromium.org

[danakj, 2015-11-13 22:45:29]

The patchset sent to the CQ was uploaded after l-g-t-m from thakis@chromium.org,
dcheng@chromium.org
Link to the patchset: https://codereview.chromium.org/1440593004/#ps140001
(title: "scopedptrequals: compilefixes")

[commit-bot: I haz the power, 2015-11-13 22:48:37]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1440593004/140001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1440593004/140001

[danakj, 2015-11-13 22:52:41]

TBR=ellyjones, sky, jochen, wez, rockot, droger

Changing various places to call .get() when comparing scoped_ptr<T> to T*,
outside of scoped_ptr, the changes are mechanical in nature.

[commit-bot: I haz the power, 2015-11-13 23:19:43]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2015-11-13 23:19:44]

Try jobs failed on following builders:
  mac_chromium_rel_ng on tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...)

[danakj, 2015-11-13 23:38:56]

The CQ bit was checked by danakj@chromium.org

[danakj, 2015-11-13 23:38:57]

The patchset sent to the CQ was uploaded after l-g-t-m from dcheng@chromium.org,
thakis@chromium.org
Link to the patchset: https://codereview.chromium.org/1440593004/#ps160001
(title: "scopedptrequals: mac-compile-fix")

[commit-bot: I haz the power, 2015-11-13 23:40:33]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1440593004/160001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1440593004/160001

[commit-bot: I haz the power, 2015-11-14 00:59:04]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2015-11-14 00:59:05]

Try jobs failed on following builders:
  win8_chromium_ng on tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win8_chromium_ng/...)
  win_chromium_x64_rel_ng on tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_x64_...)

[danakj, 2015-11-14 01:07:03]

The CQ bit was checked by danakj@chromium.org

[danakj, 2015-11-14 01:07:04]

The patchset sent to the CQ was uploaded after l-g-t-m from dcheng@chromium.org,
thakis@chromium.org
Link to the patchset: https://codereview.chromium.org/1440593004/#ps180001
(title: "scopedptrequals: windows-compile-again")

[commit-bot: I haz the power, 2015-11-14 01:07:37]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1440593004/180001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1440593004/180001

[commit-bot: I haz the power, 2015-11-14 03:25:28]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2015-11-14 03:25:30]

Try jobs failed on following builders:
  linux_android_rel_ng on tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_android_r...)

[jochen (gone - plz use gerrit), 2015-11-16 11:58:06]

lgtm

[danakj, 2015-11-16 19:04:58]

The CQ bit was checked by danakj@chromium.org

[danakj, 2015-11-16 19:04:59]

The patchset sent to the CQ was uploaded after l-g-t-m from jochen@chromium.org,
dcheng@chromium.org, thakis@chromium.org
Link to the patchset: https://codereview.chromium.org/1440593004/#ps220001
(title: "scopedptrequals: followupfix-after-rebase")

[commit-bot: I haz the power, 2015-11-16 19:06:21]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1440593004/220001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1440593004/220001

[commit-bot: I haz the power, 2015-11-16 22:09:31]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2015-11-16 22:09:32]

Try jobs failed on following builders:
  win_chromium_compile_dbg_ng on tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_comp...)
  win_chromium_rel_ng on tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_rel_...)

[danakj, 2015-11-16 22:27:59]

The CQ bit was checked by danakj@chromium.org

[commit-bot: I haz the power, 2015-11-16 22:29:20]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1440593004/220001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1440593004/220001

[commit-bot: I haz the power, 2015-11-17 00:27:56]

Committed patchset #11 (id:220001)

[commit-bot: I haz the power, 2015-11-17 00:29:01]

Patchset 11 (id:??) landed as
https://crrev.com/8199479504103bee23b5e560a96b914b9d959caf
Cr-Commit-Position: refs/heads/master@{#359957}