Rename MOVE_ONLY_TYPE_WITH_MOVE_CONSTRUCTOR_FOR_CPP_03

Rename MOVE_ONLY_TYPE_WITH_MOVE_CONSTRUCTOR_FOR_CPP_03

This renames the macro to be more standard and express its intent and
relationship to DISALLOW_COPY_AND_ASSIGN. It renames the macro to
DISALLOW_COPY_AND_ASSIGN_WITH_MOVE_FOR_BIND, as it does what
the old DISALLOW_COPY_AND_ASSIGN does, but also whitelists the type
for Bind/Callback to try move it.

R=Nico
TBR=sky
BUG=561749
Committed: https://crrev.com/6ba4c1e61a03cba5dfd7a53da70437aa61583a7f
Cr-Commit-Position: refs/heads/master@{#363712}

[danakj, 2015-12-04 21:50:15]

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

[danakj, 2015-12-04 21:50:15]

TBR=sky for mojo, search/replace of macro name

[danakj, 2015-12-04 21:51:33]

danakj@chromium.org changed reviewers:
+ phajdan.jr@chromium.org

[danakj, 2015-12-04 21:51:33]

+phajdan.jr for PRESUBMIT, removing the roll-your-own IWYU for base/macros.h, it
conflicts with this change. See discussion on
https://codereview.chromium.org/1490383004/ and
https://codereview.chromium.org/1411553003/

[danakj, 2015-12-04 21:52:29]

The CQ bit was checked by danakj@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2015-12-04 21:54:41]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1501793003/1
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1501793003/1

[Nico, 2015-12-04 21:58:05]

lgtm

https://codereview.chromium.org/1501793003/diff/1/base/move.h
File base/move.h (right):

https://codereview.chromium.org/1501793003/diff/1/base/move.h#newcode55
base/move.h:55: #define DISALLOW_COPY_AND_ASSIGN_WITH_MOVE_FOR_BIND(type)      
\
What do you think is the long term plan for this? Once Pass() is gone, this will
go away completely I guess?

Maybe this could be

#define MOVE_ONLY(x) DISALLOW_COPY_AND_ASSIGN(x)

but I guess an explicit move ctor already implicitly deletes the default copy
ctor.

[danakj, 2015-12-04 22:01:47]

https://codereview.chromium.org/1501793003/diff/1/base/move.h
File base/move.h (right):

https://codereview.chromium.org/1501793003/diff/1/base/move.h#newcode55
base/move.h:55: #define DISALLOW_COPY_AND_ASSIGN_WITH_MOVE_FOR_BIND(type)      
\
On 2015/12/04 21:58:05, Nico wrote:
> What do you think is the long term plan for this? Once Pass() is gone, this
will
> go away completely I guess?

We'll still need the typedef whitelist once Pass() is gone, until some form of
Bind/Callback works.

> Maybe this could be
> 
> #define MOVE_ONLY(x) DISALLOW_COPY_AND_ASSIGN(x)
> 
> but I guess an explicit move ctor already implicitly deletes the default copy
> ctor.

Yah it does, and this macro doesn't actually make it movable.

Long long term this macro goes away and we always use DISALLOW_COPY_AND_ASSIGN,
I think.

I could make this macro actually use DISALLOW_COPY_AND_ASSIGN instead of
re-implementing it, would that be nice do you think?

I should maybe update/slim down the comment above to say use
DISALLOW_COPY_AND_ASSIGN if you don't need Callback support.

[danakj, 2015-12-04 22:07:41]

I made the comment a lot simpler. Do you think this is better or worse than PS1?

[Nico, 2015-12-04 22:13:58]

thanks, that's much better I think. (The below are optional and mostly
internally dialog:)

https://codereview.chromium.org/1501793003/diff/20001/base/move.h
File base/move.h (right):

https://codereview.chromium.org/1501793003/diff/20001/base/move.h#newcode13
base/move.h:13: // be used in Callbacks, use
DISALLOW_COPY_AND_ASSIGN_WITH_MOVE_FOR_BIND.
we should probably have a tracking bug for doing this for all instances and then
removing this macro

https://codereview.chromium.org/1501793003/diff/20001/base/move.h#newcode36
base/move.h:36: typedef void MoveOnlyTypeForCPP03;                            \
We probably want to call this MoveOnlTypeForCallback or something and possibly
add a "TODO: Remove once $link_to_callback_move_bug is done"

[dcheng, 2015-12-04 22:14:00]

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

[dcheng, 2015-12-04 22:14:01]

https://codereview.chromium.org/1501793003/diff/1/base/move.h
File base/move.h (right):

https://codereview.chromium.org/1501793003/diff/1/base/move.h#newcode55
base/move.h:55: #define DISALLOW_COPY_AND_ASSIGN_WITH_MOVE_FOR_BIND(type)      
\
On 2015/12/04 at 22:01:47, danakj (behind on reviews) wrote:
> On 2015/12/04 21:58:05, Nico wrote:
> > What do you think is the long term plan for this? Once Pass() is gone, this
will
> > go away completely I guess?
> 
> We'll still need the typedef whitelist once Pass() is gone, until some form of
Bind/Callback works.
> 
> > Maybe this could be
> > 
> > #define MOVE_ONLY(x) DISALLOW_COPY_AND_ASSIGN(x)
> > 
> > but I guess an explicit move ctor already implicitly deletes the default
copy
> > ctor.
> 
> Yah it does, and this macro doesn't actually make it movable.
> 
> Long long term this macro goes away and we always use
DISALLOW_COPY_AND_ASSIGN, I think.
> 
> I could make this macro actually use DISALLOW_COPY_AND_ASSIGN instead of
re-implementing it, would that be nice do you think?
> 
> I should maybe update/slim down the comment above to say use
DISALLOW_COPY_AND_ASSIGN if you don't need Callback support.

I've been thinking: is there a value to forcing the use of MOVE_ONLY for
Callback compatibility? It's a pretty minor speedbump, since it's trivial to
just use this macro.

[Nico, 2015-12-04 22:15:16]

On 2015/12/04 22:14:01, dcheng wrote:
> https://codereview.chromium.org/1501793003/diff/1/base/move.h
> File base/move.h (right):
> 
> https://codereview.chromium.org/1501793003/diff/1/base/move.h#newcode55
> base/move.h:55: #define DISALLOW_COPY_AND_ASSIGN_WITH_MOVE_FOR_BIND(type)     

> \
> On 2015/12/04 at 22:01:47, danakj (behind on reviews) wrote:
> > On 2015/12/04 21:58:05, Nico wrote:
> > > What do you think is the long term plan for this? Once Pass() is gone,
this
> will
> > > go away completely I guess?
> > 
> > We'll still need the typedef whitelist once Pass() is gone, until some form
of
> Bind/Callback works.
> > 
> > > Maybe this could be
> > > 
> > > #define MOVE_ONLY(x) DISALLOW_COPY_AND_ASSIGN(x)
> > > 
> > > but I guess an explicit move ctor already implicitly deletes the default
> copy
> > > ctor.
> > 
> > Yah it does, and this macro doesn't actually make it movable.
> > 
> > Long long term this macro goes away and we always use
> DISALLOW_COPY_AND_ASSIGN, I think.
> > 
> > I could make this macro actually use DISALLOW_COPY_AND_ASSIGN instead of
> re-implementing it, would that be nice do you think?
> > 
> > I should maybe update/slim down the comment above to say use
> DISALLOW_COPY_AND_ASSIGN if you don't need Callback support.
> 
> I've been thinking: is there a value to forcing the use of MOVE_ONLY for
> Callback compatibility? It's a pretty minor speedbump, since it's trivial to
> just use this macro.

If it helps, I don't think it's horrible to keep this around. But unifying with
wtf::bind() might mean we need to figure this out somehow anyways (?)

[danakj, 2015-12-04 22:21:56]

On Fri, Dec 4, 2015 at 2:15 PM, <thakis@chromium.org> wrote:

> On 2015/12/04 22:14:01, dcheng wrote:
>
>> https://codereview.chromium.org/1501793003/diff/1/base/move.h
>> File base/move.h (right):
>>
>
> https://codereview.chromium.org/1501793003/diff/1/base/move.h#newcode55
>> base/move.h:55: #define DISALLOW_COPY_AND_ASSIGN_WITH_MOVE_FOR_BIND(type)
>>
>
> \
>> On 2015/12/04 at 22:01:47, danakj (behind on reviews) wrote:
>> > On 2015/12/04 21:58:05, Nico wrote:
>> > > What do you think is the long term plan for this? Once Pass() is gone,
>>
> this
>
>> will
>> > > go away completely I guess?
>> >
>> > We'll still need the typedef whitelist once Pass() is gone, until some
>> form
>>
> of
>
>> Bind/Callback works.
>> >
>> > > Maybe this could be
>> > >
>> > > #define MOVE_ONLY(x) DISALLOW_COPY_AND_ASSIGN(x)
>> > >
>> > > but I guess an explicit move ctor already implicitly deletes the
>> default
>> copy
>> > > ctor.
>> >
>> > Yah it does, and this macro doesn't actually make it movable.
>> >
>> > Long long term this macro goes away and we always use
>> DISALLOW_COPY_AND_ASSIGN, I think.
>> >
>> > I could make this macro actually use DISALLOW_COPY_AND_ASSIGN instead of
>> re-implementing it, would that be nice do you think?
>> >
>> > I should maybe update/slim down the comment above to say use
>> DISALLOW_COPY_AND_ASSIGN if you don't need Callback support.
>>
>
> I've been thinking: is there a value to forcing the use of MOVE_ONLY for
>> Callback compatibility? It's a pretty minor speedbump, since it's trivial
>> to
>> just use this macro.
>>
>
We require a whitelist for the internal implementation of Callback right
now, so we do need the macro.

If it helps, I don't think it's horrible to keep this around. But unifying
> with
> wtf::bind() might mean we need to figure this out somehow anyways (?)
>

From staring at callback implementation all week, I'm starting to think
that it's a bit orthogonal to the wtf::bind() stuff.

1. base::Callback already CHECK()s if you try to run a callback with a
move-only bound argument twice.
2. So if we used like a std::vector or something "undefined-y" we would
still get a well-defined crash, and it's no more weird than status quo with
our whitelisted types.
3. wtf::bind() concerns desire (a) ownership transfer of the Callback
itself and (b) single-use of the Callback. They use Passed() to achieve
(b), I guess though taking advantage of point 1 currently. Doing it at
compile-time would be nicer! But probably doesn't need to block move()ing
thru Callback without our whitelist.

Not that I have a good idea how to implement Callback without the
whitelist, but I think sammc@ has a CL to do something like this already. I
need to study his work (https://codereview.chromium.org/1498973002/).

-- 
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.

[dcheng, 2015-12-04 22:28:21]

On 2015/12/04 at 22:21:56, danakj wrote:
> On Fri, Dec 4, 2015 at 2:15 PM, <thakis@chromium.org> wrote:
> 
> > On 2015/12/04 22:14:01, dcheng wrote:
> >
> >> https://codereview.chromium.org/1501793003/diff/1/base/move.h
> >> File base/move.h (right):
> >>
> >
> > https://codereview.chromium.org/1501793003/diff/1/base/move.h#newcode55
> >> base/move.h:55: #define DISALLOW_COPY_AND_ASSIGN_WITH_MOVE_FOR_BIND(type)
> >>
> >
> > \
> >> On 2015/12/04 at 22:01:47, danakj (behind on reviews) wrote:
> >> > On 2015/12/04 21:58:05, Nico wrote:
> >> > > What do you think is the long term plan for this? Once Pass() is gone,
> >>
> > this
> >
> >> will
> >> > > go away completely I guess?
> >> >
> >> > We'll still need the typedef whitelist once Pass() is gone, until some
> >> form
> >>
> > of
> >
> >> Bind/Callback works.
> >> >
> >> > > Maybe this could be
> >> > >
> >> > > #define MOVE_ONLY(x) DISALLOW_COPY_AND_ASSIGN(x)
> >> > >
> >> > > but I guess an explicit move ctor already implicitly deletes the
> >> default
> >> copy
> >> > > ctor.
> >> >
> >> > Yah it does, and this macro doesn't actually make it movable.
> >> >
> >> > Long long term this macro goes away and we always use
> >> DISALLOW_COPY_AND_ASSIGN, I think.
> >> >
> >> > I could make this macro actually use DISALLOW_COPY_AND_ASSIGN instead of
> >> re-implementing it, would that be nice do you think?
> >> >
> >> > I should maybe update/slim down the comment above to say use
> >> DISALLOW_COPY_AND_ASSIGN if you don't need Callback support.
> >>
> >
> > I've been thinking: is there a value to forcing the use of MOVE_ONLY for
> >> Callback compatibility? It's a pretty minor speedbump, since it's trivial
> >> to
> >> just use this macro.
> >>
> >
> We require a whitelist for the internal implementation of Callback right
> now, so we do need the macro.
> 
> If it helps, I don't think it's horrible to keep this around. But unifying
> > with
> > wtf::bind() might mean we need to figure this out somehow anyways (?)
> >
> 
> From staring at callback implementation all week, I'm starting to think
> that it's a bit orthogonal to the wtf::bind() stuff.
> 
> 1. base::Callback already CHECK()s if you try to run a callback with a
> move-only bound argument twice.
> 2. So if we used like a std::vector or something "undefined-y" we would
> still get a well-defined crash, and it's no more weird than status quo with
> our whitelisted types.
> 3. wtf::bind() concerns desire (a) ownership transfer of the Callback
> itself and (b) single-use of the Callback. They use Passed() to achieve
> (b), I guess though taking advantage of point 1 currently. Doing it at
> compile-time would be nicer! But probably doesn't need to block move()ing
> thru Callback without our whitelist.
> 
> Not that I have a good idea how to implement Callback without the
> whitelist, but I think sammc@ has a CL to do something like this already. I
> need to study his work (https://codereview.chromium.org/1498973002/).

Wouldn't this just be a one-line change after
https://codereview.chromium.org/1496403002?

template<typename T>
using IsMoveOnlyType<T> = !std::is_copy_constructible<T>::value &&
std::is_move_constructible<T>::value;

We don't /need/ to get rid of CallbackForward (it's more of a 'nice to have').

> 
> -- 
> 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-12-04 22:28:34]

https://codereview.chromium.org/1501793003/diff/20001/base/move.h
File base/move.h (right):

https://codereview.chromium.org/1501793003/diff/20001/base/move.h#newcode13
base/move.h:13: // be used in Callbacks, use
DISALLOW_COPY_AND_ASSIGN_WITH_MOVE_FOR_BIND.
On 2015/12/04 22:13:58, Nico wrote:
> we should probably have a tracking bug for doing this for all instances and
then
> removing this macro

yaa I was thinking the same.. let me create and TODO it.

https://codereview.chromium.org/1501793003/diff/20001/base/move.h#newcode36
base/move.h:36: typedef void MoveOnlyTypeForCPP03;                            \
On 2015/12/04 22:13:58, Nico wrote:
> We probably want to call this MoveOnlTypeForCallback or something and possibly
> add a "TODO: Remove once $link_to_callback_move_bug is done"

Ya. I'll put a TODO to remove this whole macro for now pointing to the bug.

I was going to TODO to rename this, but TODO comments inside macros is awkward.

[danakj, 2015-12-04 22:29:16]

The CQ bit was checked by danakj@chromium.org

[danakj, 2015-12-04 22:29:16]

The patchset sent to the CQ was uploaded after l-g-t-m from thakis@chromium.org
Link to the patchset: https://codereview.chromium.org/1501793003/#ps40001
(title: "move-name: todos")

[danakj, 2015-12-04 22:36:07]

On Fri, Dec 4, 2015 at 2:28 PM, <dcheng@chromium.org> wrote:

> On 2015/12/04 at 22:21:56, danakj wrote:
>
>> On Fri, Dec 4, 2015 at 2:15 PM, <thakis@chromium.org> wrote:
>>
>
> > On 2015/12/04 22:14:01, dcheng wrote:
>> >
>> >> https://codereview.chromium.org/1501793003/diff/1/base/move.h
>> >> File base/move.h (right):
>> >>
>> >
>> > https://codereview.chromium.org/1501793003/diff/1/base/move.h#newcode55
>> >> base/move.h:55: #define
>> DISALLOW_COPY_AND_ASSIGN_WITH_MOVE_FOR_BIND(type)
>> >>
>> >
>> > \
>> >> On 2015/12/04 at 22:01:47, danakj (behind on reviews) wrote:
>> >> > On 2015/12/04 21:58:05, Nico wrote:
>> >> > > What do you think is the long term plan for this? Once Pass() is
>> gone,
>> >>
>> > this
>> >
>> >> will
>> >> > > go away completely I guess?
>> >> >
>> >> > We'll still need the typedef whitelist once Pass() is gone, until
>> some
>> >> form
>> >>
>> > of
>> >
>> >> Bind/Callback works.
>> >> >
>> >> > > Maybe this could be
>> >> > >
>> >> > > #define MOVE_ONLY(x) DISALLOW_COPY_AND_ASSIGN(x)
>> >> > >
>> >> > > but I guess an explicit move ctor already implicitly deletes the
>> >> default
>> >> copy
>> >> > > ctor.
>> >> >
>> >> > Yah it does, and this macro doesn't actually make it movable.
>> >> >
>> >> > Long long term this macro goes away and we always use
>> >> DISALLOW_COPY_AND_ASSIGN, I think.
>> >> >
>> >> > I could make this macro actually use DISALLOW_COPY_AND_ASSIGN
>> instead of
>> >> re-implementing it, would that be nice do you think?
>> >> >
>> >> > I should maybe update/slim down the comment above to say use
>> >> DISALLOW_COPY_AND_ASSIGN if you don't need Callback support.
>> >>
>> >
>> > I've been thinking: is there a value to forcing the use of MOVE_ONLY for
>> >> Callback compatibility? It's a pretty minor speedbump, since it's
>> trivial
>> >> to
>> >> just use this macro.
>> >>
>> >
>> We require a whitelist for the internal implementation of Callback right
>> now, so we do need the macro.
>>
>
> If it helps, I don't think it's horrible to keep this around. But unifying
>> > with
>> > wtf::bind() might mean we need to figure this out somehow anyways (?)
>> >
>>
>
>  From staring at callback implementation all week, I'm starting to think
>> that it's a bit orthogonal to the wtf::bind() stuff.
>>
>
> 1. base::Callback already CHECK()s if you try to run a callback with a
>> move-only bound argument twice.
>> 2. So if we used like a std::vector or something "undefined-y" we would
>> still get a well-defined crash, and it's no more weird than status quo
>> with
>> our whitelisted types.
>> 3. wtf::bind() concerns desire (a) ownership transfer of the Callback
>> itself and (b) single-use of the Callback. They use Passed() to achieve
>> (b), I guess though taking advantage of point 1 currently. Doing it at
>> compile-time would be nicer! But probably doesn't need to block move()ing
>> thru Callback without our whitelist.
>>
>
> Not that I have a good idea how to implement Callback without the
>> whitelist, but I think sammc@ has a CL to do something like this
>> already. I
>> need to study his work (https://codereview.chromium.org/1498973002/).
>>
>
> Wouldn't this just be a one-line change after
> https://codereview.chromium.org/1496403002?
>
> template<typename T>
> using IsMoveOnlyType<T> = !std::is_copy_constructible<T>::value &&
> std::is_move_constructible<T>::value;
>
> We don't /need/ to get rid of CallbackForward (it's more of a 'nice to
> have').
>

Oh, ya... I think that you're right. I guess the rest is follow-up cleanups.


>
>
> --
>> 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.
>
>
> https://codereview.chromium.org/1501793003/
>

-- 
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-12-04 22:36:49]

Description was changed from

==========
Rename MOVE_ONLY_TYPE_WITH_MOVE_CONSTRUCTOR_FOR_CPP_03

This renames the macro to be more standard and express its intent and
relationship to DISALLOW_COPY_AND_ASSIGN. It renames the macro to
DISALLOW_COPY_AND_ASSIGN_WITH_MOVE_FOR_BIND, as it does what
the old DISALLOW_COPY_AND_ASSIGN does, but also whitelists the type
for Bind/Callback to try move it.

R=Nico
BUG=561749
==========

to

==========
Rename MOVE_ONLY_TYPE_WITH_MOVE_CONSTRUCTOR_FOR_CPP_03

This renames the macro to be more standard and express its intent and
relationship to DISALLOW_COPY_AND_ASSIGN. It renames the macro to
DISALLOW_COPY_AND_ASSIGN_WITH_MOVE_FOR_BIND, as it does what
the old DISALLOW_COPY_AND_ASSIGN does, but also whitelists the type
for Bind/Callback to try move it.

R=Nico
BUG=561749
==========

[danakj, 2015-12-04 22:43:29]

Description was changed from

==========
Rename MOVE_ONLY_TYPE_WITH_MOVE_CONSTRUCTOR_FOR_CPP_03

This renames the macro to be more standard and express its intent and
relationship to DISALLOW_COPY_AND_ASSIGN. It renames the macro to
DISALLOW_COPY_AND_ASSIGN_WITH_MOVE_FOR_BIND, as it does what
the old DISALLOW_COPY_AND_ASSIGN does, but also whitelists the type
for Bind/Callback to try move it.

R=Nico
BUG=561749
==========

to

==========
Rename MOVE_ONLY_TYPE_WITH_MOVE_CONSTRUCTOR_FOR_CPP_03

This renames the macro to be more standard and express its intent and
relationship to DISALLOW_COPY_AND_ASSIGN. It renames the macro to
DISALLOW_COPY_AND_ASSIGN_WITH_MOVE_FOR_BIND, as it does what
the old DISALLOW_COPY_AND_ASSIGN does, but also whitelists the type
for Bind/Callback to try move it.

R=Nico
TBR=sky
BUG=561749
==========

[commit-bot: I haz the power, 2015-12-04 22:48:29]

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

[commit-bot: I haz the power, 2015-12-05 00:41:37]

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

[commit-bot: I haz the power, 2015-12-05 00:41:37]

Try jobs failed on following builders:
  win8_chromium_ng on tryserver.chromium.win (JOB_TIMED_OUT, no build URL)
  win_chromium_compile_dbg_ng on tryserver.chromium.win (JOB_TIMED_OUT, no build
URL)
  win_chromium_rel_ng on tryserver.chromium.win (JOB_TIMED_OUT, no build URL)
  win_chromium_x64_rel_ng on tryserver.chromium.win (JOB_TIMED_OUT, no build
URL)

[danakj, 2015-12-07 18:56:58]

The CQ bit was checked by danakj@chromium.org

[commit-bot: I haz the power, 2015-12-07 18:59:34]

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

[commit-bot: I haz the power, 2015-12-08 00:11:17]

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

[commit-bot: I haz the power, 2015-12-08 00:11:18]

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

[danakj, 2015-12-08 00:37:24]

The CQ bit was checked by danakj@chromium.org

[commit-bot: I haz the power, 2015-12-08 00:42:43]

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

[commit-bot: I haz the power, 2015-12-08 02:31:00]

Description was changed from

==========
Rename MOVE_ONLY_TYPE_WITH_MOVE_CONSTRUCTOR_FOR_CPP_03

This renames the macro to be more standard and express its intent and
relationship to DISALLOW_COPY_AND_ASSIGN. It renames the macro to
DISALLOW_COPY_AND_ASSIGN_WITH_MOVE_FOR_BIND, as it does what
the old DISALLOW_COPY_AND_ASSIGN does, but also whitelists the type
for Bind/Callback to try move it.

R=Nico
TBR=sky
BUG=561749
==========

to

==========
Rename MOVE_ONLY_TYPE_WITH_MOVE_CONSTRUCTOR_FOR_CPP_03

This renames the macro to be more standard and express its intent and
relationship to DISALLOW_COPY_AND_ASSIGN. It renames the macro to
DISALLOW_COPY_AND_ASSIGN_WITH_MOVE_FOR_BIND, as it does what
the old DISALLOW_COPY_AND_ASSIGN does, but also whitelists the type
for Bind/Callback to try move it.

R=Nico
TBR=sky
BUG=561749
==========

[commit-bot: I haz the power, 2015-12-08 02:31:01]

Committed patchset #3 (id:40001)

[commit-bot: I haz the power, 2015-12-08 02:32:04]

Description was changed from

==========
Rename MOVE_ONLY_TYPE_WITH_MOVE_CONSTRUCTOR_FOR_CPP_03

This renames the macro to be more standard and express its intent and
relationship to DISALLOW_COPY_AND_ASSIGN. It renames the macro to
DISALLOW_COPY_AND_ASSIGN_WITH_MOVE_FOR_BIND, as it does what
the old DISALLOW_COPY_AND_ASSIGN does, but also whitelists the type
for Bind/Callback to try move it.

R=Nico
TBR=sky
BUG=561749
==========

to

==========
Rename MOVE_ONLY_TYPE_WITH_MOVE_CONSTRUCTOR_FOR_CPP_03

This renames the macro to be more standard and express its intent and
relationship to DISALLOW_COPY_AND_ASSIGN. It renames the macro to
DISALLOW_COPY_AND_ASSIGN_WITH_MOVE_FOR_BIND, as it does what
the old DISALLOW_COPY_AND_ASSIGN does, but also whitelists the type
for Bind/Callback to try move it.

R=Nico
TBR=sky
BUG=561749

Committed: https://crrev.com/6ba4c1e61a03cba5dfd7a53da70437aa61583a7f
Cr-Commit-Position: refs/heads/master@{#363712}
==========

[commit-bot: I haz the power, 2015-12-08 02:32:05]

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