Remove remaining calls to deprecated MessageLoop methods.

Remove remaining calls to deprecated MessageLoop methods.

This CL makes the following replacements everywhere:

Before               After
----------------------------------------------------------
 x.PostTask()          x.task_runner()->PostTask()
   PostDelayedTask()                    PostDelayedTask()
   ReleaseSoon()                        ReleaseSoon()
   DeleteSoon()                         DeleteSoon()

x->PostTask()         y->task_runner()->PostTask()
   PostDelayedTask()                    PostDelayedTask()
   ReleaseSoon()                        ReleaseSoon()
   DeleteSoon()                         DeleteSoon()

 x.Run()              RunLoop().Run()
 x.RunUntilIdle()     RunLoop().RunUntilIdle()

x->Run()              RunLoop().Run()
x->RunUntilIdle()     RunLoop().RunUntilIdle()
    If |x| isn't MessageLoopForUI::current() or
    MessageLoopForIO::current()
----------------------------------------------------------

|x| is a base::MessageLoop(ForUI|ForIO) or a pointer to
a base::MessageLoop(ForUI|ForIO).

This CL was generated using the MessageLoopDeprecatedMethods
clang-tidy fix available on the associated bug. Only files
that compile on Mac are affected. Follow-up CLs will make
these replacements for other platforms.

This CL doesn't change code behavior.

TBR=garykac@chromium.org
BUG=616447
Committed: https://crrev.com/6d056ff7a8b9cadcd19dba50d20059428aa1db9b
Cr-Commit-Position: refs/heads/master@{#403716}

[fdoray, 2016-06-30 13:59:00]

fdoray@chromium.org changed reviewers:
+ ben@chromium.org, caitkp@chromium.org, chcunningham@chromium.org,
garykac@chromium.org, jam@chromium.org, jochen@chromium.org

[fdoray, 2016-06-30 13:59:01]

Can you take a look at this CL?

chrome/ jochen@chromium.org
components/ caitkp@chromium.org
content/ jochen@chromium.org
ipc/ jam@chromium.org
media/ chcunningham@chromium.org
mojo/ ben@chromium.org
remoting/ garykac@chromium.org
services/ jam@chromium.org

[fdoray, 2016-06-30 13:59:35]

Description was changed from

==========
Remove remaining calls to deprecated MessageLoop methods.

This CL makes the following replacements everywhere:

Before               After
----------------------------------------------------------
 x.PostTask()          x.task_runner()->PostTask()
   PostDelayedTask()                    PostDelayedTask()
   ReleaseSoon()                        ReleaseSoon()
   DeleteSoon()                         DeleteSoon()

x->PostTask()         y->task_runner()->PostTask()
   PostDelayedTask()                    PostDelayedTask()
   ReleaseSoon()                        ReleaseSoon()
   DeleteSoon()                         DeleteSoon()

 x.Run()              RunLoop().Run()
 x.RunUntilIdle()     RunLoop().RunUntilIdle()

x->Run()              RunLoop().Run()
x->RunUntilIdle()     RunLoop().RunUntilIdle()
    If |x| isn't MessageLoopForUI::current() or
    MessageLoopForIO::current()
----------------------------------------------------------

|x| is a base::MessageLoop(ForUI|ForIO) or a pointer to
a base::MessageLoop(ForUI|ForIO).

This CL was generated using the MessageLoopDeprecatedMethods
clang-tidy fix available on the associated bug. Only files
that compile on Mac are affected. Follow-up CLs will make
these replacements for other platforms.

This CL doesn't change code behavior.

BUG=616447
==========

to

==========
Remove remaining calls to deprecated MessageLoop methods.

This CL makes the following replacements everywhere:

Before               After
----------------------------------------------------------
 x.PostTask()          x.task_runner()->PostTask()
   PostDelayedTask()                    PostDelayedTask()
   ReleaseSoon()                        ReleaseSoon()
   DeleteSoon()                         DeleteSoon()

x->PostTask()         y->task_runner()->PostTask()
   PostDelayedTask()                    PostDelayedTask()
   ReleaseSoon()                        ReleaseSoon()
   DeleteSoon()                         DeleteSoon()

 x.Run()              RunLoop().Run()
 x.RunUntilIdle()     RunLoop().RunUntilIdle()

x->Run()              RunLoop().Run()
x->RunUntilIdle()     RunLoop().RunUntilIdle()
    If |x| isn't MessageLoopForUI::current() or
    MessageLoopForIO::current()
----------------------------------------------------------

|x| is a base::MessageLoop(ForUI|ForIO) or a pointer to
a base::MessageLoop(ForUI|ForIO).

This CL was generated using the MessageLoopDeprecatedMethods
clang-tidy fix available on the associated bug. Only files
that compile on Mac are affected. Follow-up CLs will make
these replacements for other platforms.

This CL doesn't change code behavior.

TBR=jochen@chromium.org,caitkp@chromium.org,jam@chromium.org,chcunningham@chr...
BUG=616447
==========

[jochen (gone - plz use gerrit), 2016-06-30 15:17:23]

can you please find somebody from your team to review this CL first? Preferably
somebody that knows about the clang-tidy script.

Please also don't use TBR=

[Ben Goodger (Google), 2016-06-30 15:30:54]

lgtm

[fdoray, 2016-06-30 17:25:39]

fdoray@chromium.org changed reviewers:
+ gab@chromium.org

[fdoray, 2016-06-30 17:30:09]

On 2016/06/30 15:17:23, jochen wrote:
> can you please find somebody from your team to review this CL first?
Preferably
> somebody that knows about the clang-tidy script.
> 
> Please also don't use TBR=

+gab@: Can you review this CL?

I used TBR because a lot of CLs generated by the same script have already landed
+ this CL doesn't change code behavior. I'm happy to wait for LGTMs if needed.

[Sergey Ulanov, 2016-06-30 18:31:28]

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

[Sergey Ulanov, 2016-06-30 18:31:28]

remoting lgtm

[gab, 2016-06-30 20:28:18]

lgtm w/ comments because this gets us closer to removing long-deprecated
MessageLoop methods, but, as highlighted below and discussed offline, it does
introduce some non-ideal paradigms (which we are okay to take as a compromise).

https://codereview.chromium.org/2104363004/diff/20001/media/test/pipeline_int...
File media/test/pipeline_integration_test.cc (left):

https://codereview.chromium.org/2104363004/diff/20001/media/test/pipeline_int...
media/test/pipeline_integration_test.cc:792: message_loop_.Run();
Feels a bit weird to replace a member call by a static call (especially when the
member itself is not fully removed). Should the exposed member be a RunLoop? Or
should it just be a private MessageLoop member in the fixture and the tests use
ThreadTaskRunnerHandle::Get() and base:RunLoop() statically everywhere?


Edit after offline discussion (writing here for posterity):

In tests, we agree that it makes for MessageLoop to be a private member and
everyone use the static methods (TaskRunnerHandle to post / RunLoop to run).
This is similar to TestBrowserThreadBundle's existing paradigm, the MessageLoop
member merely instantiates something to allow tests that need to post/run tasks
to do so. Using static methods is better because that member could easily be
swapped out for something else that also supports these static methods (e.g. an
eventual TestTaskScheduler).

Changing all tests at scale to use this paradigm is a huge undertaking and isn't
easily automated. As such, replacing the member Run() call with
base::RunLoop()::Run() is acceptable (it's actually the same thing in practice,
MessageLoop::Run() used to do just that and not actually guarantee to run the
loop of the actual instance..!) as it at least allows the removal of
MessageLoop::Run() and will force future tests to use the aforementioned
paradigm.

Where would be a good place in the codebase to document the recommended
paradigm?

https://codereview.chromium.org/2104363004/diff/20001/mojo/public/cpp/binding...
File mojo/public/cpp/bindings/tests/union_unittest.cc (right):

https://codereview.chromium.org/2104363004/diff/20001/mojo/public/cpp/binding...
mojo/public/cpp/bindings/tests/union_unittest.cc:1252: base::MessageLoop
run_loop;
Rename this to |message_loop|, the name was already wrong, but now it's just
plain confusing!

https://codereview.chromium.org/2104363004/diff/20001/remoting/protocol/chann...
File remoting/protocol/channel_multiplexer_unittest.cc (right):

https://codereview.chromium.org/2104363004/diff/20001/remoting/protocol/chann...
remoting/protocol/channel_multiplexer_unittest.cc:127: base::MessageLoop
message_loop_;
Can be made private now

https://codereview.chromium.org/2104363004/diff/20001/remoting/protocol/conne...
File remoting/protocol/connection_tester.cc (right):

https://codereview.chromium.org/2104363004/diff/20001/remoting/protocol/conne...
remoting/protocol/connection_tester.cc:142: :
message_loop_(base::MessageLoop::current()),
This could be TaskRunnerHandle and then no need for MessageLoop anywhere in this
file.

https://codereview.chromium.org/2104363004/diff/20001/remoting/protocol/negot...
File remoting/protocol/negotiating_authenticator_unittest.cc (left):

https://codereview.chromium.org/2104363004/diff/20001/remoting/protocol/negot...
remoting/protocol/negotiating_authenticator_unittest.cc:144:
message_loop_.Run();
No longer using the member, maybe AuthenticatorTestBase can make it private?

Also note another weird use case here..: AuthenticatorTestBase will potentially
have a member which subclasses depend on but don't refer to..

[jam, 2016-06-30 22:14:37]

lgtm

[jochen (gone - plz use gerrit), 2016-07-01 14:13:21]

lgtm

[chcunningham, 2016-07-01 15:41:39]

media lgtm

[fdoray, 2016-07-04 13:58:11]

Description was changed from

==========
Remove remaining calls to deprecated MessageLoop methods.

This CL makes the following replacements everywhere:

Before               After
----------------------------------------------------------
 x.PostTask()          x.task_runner()->PostTask()
   PostDelayedTask()                    PostDelayedTask()
   ReleaseSoon()                        ReleaseSoon()
   DeleteSoon()                         DeleteSoon()

x->PostTask()         y->task_runner()->PostTask()
   PostDelayedTask()                    PostDelayedTask()
   ReleaseSoon()                        ReleaseSoon()
   DeleteSoon()                         DeleteSoon()

 x.Run()              RunLoop().Run()
 x.RunUntilIdle()     RunLoop().RunUntilIdle()

x->Run()              RunLoop().Run()
x->RunUntilIdle()     RunLoop().RunUntilIdle()
    If |x| isn't MessageLoopForUI::current() or
    MessageLoopForIO::current()
----------------------------------------------------------

|x| is a base::MessageLoop(ForUI|ForIO) or a pointer to
a base::MessageLoop(ForUI|ForIO).

This CL was generated using the MessageLoopDeprecatedMethods
clang-tidy fix available on the associated bug. Only files
that compile on Mac are affected. Follow-up CLs will make
these replacements for other platforms.

This CL doesn't change code behavior.

TBR=jochen@chromium.org,caitkp@chromium.org,jam@chromium.org,chcunningham@chr...
BUG=616447
==========

to

==========
Remove remaining calls to deprecated MessageLoop methods.

This CL makes the following replacements everywhere:

Before               After
----------------------------------------------------------
 x.PostTask()          x.task_runner()->PostTask()
   PostDelayedTask()                    PostDelayedTask()
   ReleaseSoon()                        ReleaseSoon()
   DeleteSoon()                         DeleteSoon()

x->PostTask()         y->task_runner()->PostTask()
   PostDelayedTask()                    PostDelayedTask()
   ReleaseSoon()                        ReleaseSoon()
   DeleteSoon()                         DeleteSoon()

 x.Run()              RunLoop().Run()
 x.RunUntilIdle()     RunLoop().RunUntilIdle()

x->Run()              RunLoop().Run()
x->RunUntilIdle()     RunLoop().RunUntilIdle()
    If |x| isn't MessageLoopForUI::current() or
    MessageLoopForIO::current()
----------------------------------------------------------

|x| is a base::MessageLoop(ForUI|ForIO) or a pointer to
a base::MessageLoop(ForUI|ForIO).

This CL was generated using the MessageLoopDeprecatedMethods
clang-tidy fix available on the associated bug. Only files
that compile on Mac are affected. Follow-up CLs will make
these replacements for other platforms.

This CL doesn't change code behavior.

TBR=caitkp@chromium.org,garykac@chromium.org
BUG=616447
==========

[fdoray, 2016-07-04 13:59:47]

https://codereview.chromium.org/2104363004/diff/20001/media/test/pipeline_int...
File media/test/pipeline_integration_test.cc (left):

https://codereview.chromium.org/2104363004/diff/20001/media/test/pipeline_int...
media/test/pipeline_integration_test.cc:792: message_loop_.Run();
On 2016/06/30 20:28:18, gab wrote:
> Feels a bit weird to replace a member call by a static call (especially when
the
> member itself is not fully removed). Should the exposed member be a RunLoop?
Or
> should it just be a private MessageLoop member in the fixture and the tests
use
> ThreadTaskRunnerHandle::Get() and base:RunLoop() statically everywhere?
> 
> 
> Edit after offline discussion (writing here for posterity):
> 
> In tests, we agree that it makes for MessageLoop to be a private member and
> everyone use the static methods (TaskRunnerHandle to post / RunLoop to run).
> This is similar to TestBrowserThreadBundle's existing paradigm, the
MessageLoop
> member merely instantiates something to allow tests that need to post/run
tasks
> to do so. Using static methods is better because that member could easily be
> swapped out for something else that also supports these static methods (e.g.
an
> eventual TestTaskScheduler).
> 
> Changing all tests at scale to use this paradigm is a huge undertaking and
isn't
> easily automated. As such, replacing the member Run() call with
> base::RunLoop()::Run() is acceptable (it's actually the same thing in
practice,
> MessageLoop::Run() used to do just that and not actually guarantee to run the
> loop of the actual instance..!) as it at least allows the removal of
> MessageLoop::Run() and will force future tests to use the aforementioned
> paradigm.
> 
> Where would be a good place in the codebase to document the recommended
> paradigm?

MessageLoop::Run() and MessageLoop::RunUntilIdle() will be removed so everybody
will be forced to use RunLoop.

We should add a comment on MessageLoop::task_runner() to say that
ThreadTaskRunnerHandle::Get() must be used instead of
MessageLoop::current()->task_runner().

Could we add a presubmit check to make sure that MessageLoop is always private
in tests? I don't see a good reason to make it public/protected:
- ThreadTaskRunnerHandle should be used to post tasks.
- RunLoop should be used to run the MessageLoop.
- Special methods (AddTaskObserver, AddDestructionObserver,
WatchFileDescriptor...) are not thread-safe. MessageLoop::current()->... should
be used to call these methods.

https://codereview.chromium.org/2104363004/diff/20001/mojo/public/cpp/binding...
File mojo/public/cpp/bindings/tests/union_unittest.cc (right):

https://codereview.chromium.org/2104363004/diff/20001/mojo/public/cpp/binding...
mojo/public/cpp/bindings/tests/union_unittest.cc:1252: base::MessageLoop
run_loop;
On 2016/06/30 20:28:18, gab wrote:
> Rename this to |message_loop|, the name was already wrong, but now it's just
> plain confusing!

Done.

https://codereview.chromium.org/2104363004/diff/20001/remoting/protocol/chann...
File remoting/protocol/channel_multiplexer_unittest.cc (right):

https://codereview.chromium.org/2104363004/diff/20001/remoting/protocol/chann...
remoting/protocol/channel_multiplexer_unittest.cc:127: base::MessageLoop
message_loop_;
On 2016/06/30 20:28:18, gab wrote:
> Can be made private now

Done.

https://codereview.chromium.org/2104363004/diff/20001/remoting/protocol/conne...
File remoting/protocol/connection_tester.cc (right):

https://codereview.chromium.org/2104363004/diff/20001/remoting/protocol/conne...
remoting/protocol/connection_tester.cc:142: :
message_loop_(base::MessageLoop::current()),
On 2016/06/30 20:28:18, gab wrote:
> This could be TaskRunnerHandle and then no need for MessageLoop anywhere in
this
> file.

Done.

https://codereview.chromium.org/2104363004/diff/20001/remoting/protocol/negot...
File remoting/protocol/negotiating_authenticator_unittest.cc (left):

https://codereview.chromium.org/2104363004/diff/20001/remoting/protocol/negot...
remoting/protocol/negotiating_authenticator_unittest.cc:144:
message_loop_.Run();
On 2016/06/30 20:28:18, gab wrote:
> No longer using the member, maybe AuthenticatorTestBase can make it private?
> 
> Also note another weird use case here..: AuthenticatorTestBase will
potentially
> have a member which subclasses depend on but don't refer to.. 

Done.

[gab, 2016-07-04 14:47:06]

lgtm w/ nits

https://codereview.chromium.org/2104363004/diff/20001/media/test/pipeline_int...
File media/test/pipeline_integration_test.cc (left):

https://codereview.chromium.org/2104363004/diff/20001/media/test/pipeline_int...
media/test/pipeline_integration_test.cc:792: message_loop_.Run();
On 2016/07/04 13:59:46, fdoray wrote:
> On 2016/06/30 20:28:18, gab wrote:
> > Feels a bit weird to replace a member call by a static call (especially when
> the
> > member itself is not fully removed). Should the exposed member be a RunLoop?
> Or
> > should it just be a private MessageLoop member in the fixture and the tests
> use
> > ThreadTaskRunnerHandle::Get() and base:RunLoop() statically everywhere?
> > 
> > 
> > Edit after offline discussion (writing here for posterity):
> > 
> > In tests, we agree that it makes for MessageLoop to be a private member and
> > everyone use the static methods (TaskRunnerHandle to post / RunLoop to run).
> > This is similar to TestBrowserThreadBundle's existing paradigm, the
> MessageLoop
> > member merely instantiates something to allow tests that need to post/run
> tasks
> > to do so. Using static methods is better because that member could easily be
> > swapped out for something else that also supports these static methods (e.g.
> an
> > eventual TestTaskScheduler).
> > 
> > Changing all tests at scale to use this paradigm is a huge undertaking and
> isn't
> > easily automated. As such, replacing the member Run() call with
> > base::RunLoop()::Run() is acceptable (it's actually the same thing in
> practice,
> > MessageLoop::Run() used to do just that and not actually guarantee to run
the
> > loop of the actual instance..!) as it at least allows the removal of
> > MessageLoop::Run() and will force future tests to use the aforementioned
> > paradigm.
> > 
> > Where would be a good place in the codebase to document the recommended
> > paradigm?
> 
> MessageLoop::Run() and MessageLoop::RunUntilIdle() will be removed so
everybody
> will be forced to use RunLoop.
> 
> We should add a comment on MessageLoop::task_runner() to say that
> ThreadTaskRunnerHandle::Get() must be used instead of
> MessageLoop::current()->task_runner().
> 
> Could we add a presubmit check to make sure that MessageLoop is always private
> in tests? I don't see a good reason to make it public/protected:
> - ThreadTaskRunnerHandle should be used to post tasks.
> - RunLoop should be used to run the MessageLoop.
> - Special methods (AddTaskObserver, AddDestructionObserver,
> WatchFileDescriptor...) are not thread-safe. MessageLoop::current()->...
should
> be used to call these methods.
> 

Hmm I don't think there's precedent for such a presubmit check (ensuring a
specific section of class definition is used for a member), but maybe it could
make sense. Only if the desired paradigm is documented somewhere in the codebase
and this is merely intended to point users who missed that documentation back to
it.

(definitely as a follow-up CL, not in this one, though; just to make sure we're
on the same page)

https://codereview.chromium.org/2104363004/diff/60001/remoting/protocol/authe...
File remoting/protocol/authenticator_test_base.h (right):

https://codereview.chromium.org/2104363004/diff/60001/remoting/protocol/authe...
remoting/protocol/authenticator_test_base.h:53: private:
private section at bottom and including DISALLOW_COPY_AND_ASSIGN?

https://codereview.chromium.org/2104363004/diff/60001/remoting/protocol/chann...
File remoting/protocol/channel_multiplexer_unittest.cc (right):

https://codereview.chromium.org/2104363004/diff/60001/remoting/protocol/chann...
remoting/protocol/channel_multiplexer_unittest.cc:128: base::MessageLoop
message_loop_;
ditto

[fdoray, 2016-07-04 16:33:59]

https://codereview.chromium.org/2104363004/diff/20001/media/test/pipeline_int...
File media/test/pipeline_integration_test.cc (left):

https://codereview.chromium.org/2104363004/diff/20001/media/test/pipeline_int...
media/test/pipeline_integration_test.cc:792: message_loop_.Run();
On 2016/07/04 14:47:06, gab wrote:
> On 2016/07/04 13:59:46, fdoray wrote:
> > On 2016/06/30 20:28:18, gab wrote:
> > > Feels a bit weird to replace a member call by a static call (especially
when
> > the
> > > member itself is not fully removed). Should the exposed member be a
RunLoop?
> > Or
> > > should it just be a private MessageLoop member in the fixture and the
tests
> > use
> > > ThreadTaskRunnerHandle::Get() and base:RunLoop() statically everywhere?
> > > 
> > > 
> > > Edit after offline discussion (writing here for posterity):
> > > 
> > > In tests, we agree that it makes for MessageLoop to be a private member
and
> > > everyone use the static methods (TaskRunnerHandle to post / RunLoop to
run).
> > > This is similar to TestBrowserThreadBundle's existing paradigm, the
> > MessageLoop
> > > member merely instantiates something to allow tests that need to post/run
> > tasks
> > > to do so. Using static methods is better because that member could easily
be
> > > swapped out for something else that also supports these static methods
(e.g.
> > an
> > > eventual TestTaskScheduler).
> > > 
> > > Changing all tests at scale to use this paradigm is a huge undertaking and
> > isn't
> > > easily automated. As such, replacing the member Run() call with
> > > base::RunLoop()::Run() is acceptable (it's actually the same thing in
> > practice,
> > > MessageLoop::Run() used to do just that and not actually guarantee to run
> the
> > > loop of the actual instance..!) as it at least allows the removal of
> > > MessageLoop::Run() and will force future tests to use the aforementioned
> > > paradigm.
> > > 
> > > Where would be a good place in the codebase to document the recommended
> > > paradigm?
> > 
> > MessageLoop::Run() and MessageLoop::RunUntilIdle() will be removed so
> everybody
> > will be forced to use RunLoop.
> > 
> > We should add a comment on MessageLoop::task_runner() to say that
> > ThreadTaskRunnerHandle::Get() must be used instead of
> > MessageLoop::current()->task_runner().
> > 
> > Could we add a presubmit check to make sure that MessageLoop is always
private
> > in tests? I don't see a good reason to make it public/protected:
> > - ThreadTaskRunnerHandle should be used to post tasks.
> > - RunLoop should be used to run the MessageLoop.
> > - Special methods (AddTaskObserver, AddDestructionObserver,
> > WatchFileDescriptor...) are not thread-safe. MessageLoop::current()->...
> should
> > be used to call these methods.
> > 
> 
> Hmm I don't think there's precedent for such a presubmit check (ensuring a
> specific section of class definition is used for a member), but maybe it could
> make sense. Only if the desired paradigm is documented somewhere in the
codebase
> and this is merely intended to point users who missed that documentation back
to
> it.
> 
> (definitely as a follow-up CL, not in this one, though; just to make sure
we're
> on the same page)

Will document the desired paradigm in a separate CL.

https://codereview.chromium.org/2104363004/diff/60001/remoting/protocol/authe...
File remoting/protocol/authenticator_test_base.h (right):

https://codereview.chromium.org/2104363004/diff/60001/remoting/protocol/authe...
remoting/protocol/authenticator_test_base.h:53: private:
On 2016/07/04 14:47:06, gab wrote:
> private section at bottom and including DISALLOW_COPY_AND_ASSIGN?

Done.

https://codereview.chromium.org/2104363004/diff/60001/remoting/protocol/chann...
File remoting/protocol/channel_multiplexer_unittest.cc (right):

https://codereview.chromium.org/2104363004/diff/60001/remoting/protocol/chann...
remoting/protocol/channel_multiplexer_unittest.cc:128: base::MessageLoop
message_loop_;
On 2016/07/04 14:47:06, gab wrote:
> ditto

Doesn't work because the constructor of FakeStreamChannelFactory calls
ThreadTaskRunnerHandle::Get() (a MessageLoop must be instantiated before
FakeStreamChannelFactory).

[gab, 2016-07-04 17:24:14]

lgtm

https://codereview.chromium.org/2104363004/diff/60001/remoting/protocol/chann...
File remoting/protocol/channel_multiplexer_unittest.cc (right):

https://codereview.chromium.org/2104363004/diff/60001/remoting/protocol/chann...
remoting/protocol/channel_multiplexer_unittest.cc:128: base::MessageLoop
message_loop_;
On 2016/07/04 16:33:59, fdoray wrote:
> On 2016/07/04 14:47:06, gab wrote:
> > ditto
> 
> Doesn't work because the constructor of FakeStreamChannelFactory calls
> ThreadTaskRunnerHandle::Get() (a MessageLoop must be instantiated before
> FakeStreamChannelFactory).

Ok, thanks for adding justification comment.

[Cait (Slow), 2016-07-04 21:06:44]

components lgtm

[fdoray, 2016-07-04 21:08:12]

The CQ bit was checked by fdoray@chromium.org

[fdoray, 2016-07-04 21:08:13]

The patchset sent to the CQ was uploaded after l-g-t-m from
sergeyu@chromium.org, ben@chromium.org, jochen@chromium.org, jam@chromium.org,
chcunningham@chromium.org
Link to the patchset: https://codereview.chromium.org/2104363004/#ps80001
(title: "CR gab")

[commit-bot: I haz the power, 2016-07-04 21:08:22]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[fdoray, 2016-07-04 21:08:27]

Description was changed from

==========
Remove remaining calls to deprecated MessageLoop methods.

This CL makes the following replacements everywhere:

Before               After
----------------------------------------------------------
 x.PostTask()          x.task_runner()->PostTask()
   PostDelayedTask()                    PostDelayedTask()
   ReleaseSoon()                        ReleaseSoon()
   DeleteSoon()                         DeleteSoon()

x->PostTask()         y->task_runner()->PostTask()
   PostDelayedTask()                    PostDelayedTask()
   ReleaseSoon()                        ReleaseSoon()
   DeleteSoon()                         DeleteSoon()

 x.Run()              RunLoop().Run()
 x.RunUntilIdle()     RunLoop().RunUntilIdle()

x->Run()              RunLoop().Run()
x->RunUntilIdle()     RunLoop().RunUntilIdle()
    If |x| isn't MessageLoopForUI::current() or
    MessageLoopForIO::current()
----------------------------------------------------------

|x| is a base::MessageLoop(ForUI|ForIO) or a pointer to
a base::MessageLoop(ForUI|ForIO).

This CL was generated using the MessageLoopDeprecatedMethods
clang-tidy fix available on the associated bug. Only files
that compile on Mac are affected. Follow-up CLs will make
these replacements for other platforms.

This CL doesn't change code behavior.

TBR=caitkp@chromium.org,garykac@chromium.org
BUG=616447
==========

to

==========
Remove remaining calls to deprecated MessageLoop methods.

This CL makes the following replacements everywhere:

Before               After
----------------------------------------------------------
 x.PostTask()          x.task_runner()->PostTask()
   PostDelayedTask()                    PostDelayedTask()
   ReleaseSoon()                        ReleaseSoon()
   DeleteSoon()                         DeleteSoon()

x->PostTask()         y->task_runner()->PostTask()
   PostDelayedTask()                    PostDelayedTask()
   ReleaseSoon()                        ReleaseSoon()
   DeleteSoon()                         DeleteSoon()

 x.Run()              RunLoop().Run()
 x.RunUntilIdle()     RunLoop().RunUntilIdle()

x->Run()              RunLoop().Run()
x->RunUntilIdle()     RunLoop().RunUntilIdle()
    If |x| isn't MessageLoopForUI::current() or
    MessageLoopForIO::current()
----------------------------------------------------------

|x| is a base::MessageLoop(ForUI|ForIO) or a pointer to
a base::MessageLoop(ForUI|ForIO).

This CL was generated using the MessageLoopDeprecatedMethods
clang-tidy fix available on the associated bug. Only files
that compile on Mac are affected. Follow-up CLs will make
these replacements for other platforms.

This CL doesn't change code behavior.

TBR=garykac@chromium.org
BUG=616447
==========

[commit-bot: I haz the power, 2016-07-04 21:56:57]

Description was changed from

==========
Remove remaining calls to deprecated MessageLoop methods.

This CL makes the following replacements everywhere:

Before               After
----------------------------------------------------------
 x.PostTask()          x.task_runner()->PostTask()
   PostDelayedTask()                    PostDelayedTask()
   ReleaseSoon()                        ReleaseSoon()
   DeleteSoon()                         DeleteSoon()

x->PostTask()         y->task_runner()->PostTask()
   PostDelayedTask()                    PostDelayedTask()
   ReleaseSoon()                        ReleaseSoon()
   DeleteSoon()                         DeleteSoon()

 x.Run()              RunLoop().Run()
 x.RunUntilIdle()     RunLoop().RunUntilIdle()

x->Run()              RunLoop().Run()
x->RunUntilIdle()     RunLoop().RunUntilIdle()
    If |x| isn't MessageLoopForUI::current() or
    MessageLoopForIO::current()
----------------------------------------------------------

|x| is a base::MessageLoop(ForUI|ForIO) or a pointer to
a base::MessageLoop(ForUI|ForIO).

This CL was generated using the MessageLoopDeprecatedMethods
clang-tidy fix available on the associated bug. Only files
that compile on Mac are affected. Follow-up CLs will make
these replacements for other platforms.

This CL doesn't change code behavior.

TBR=garykac@chromium.org
BUG=616447
==========

to

==========
Remove remaining calls to deprecated MessageLoop methods.

This CL makes the following replacements everywhere:

Before               After
----------------------------------------------------------
 x.PostTask()          x.task_runner()->PostTask()
   PostDelayedTask()                    PostDelayedTask()
   ReleaseSoon()                        ReleaseSoon()
   DeleteSoon()                         DeleteSoon()

x->PostTask()         y->task_runner()->PostTask()
   PostDelayedTask()                    PostDelayedTask()
   ReleaseSoon()                        ReleaseSoon()
   DeleteSoon()                         DeleteSoon()

 x.Run()              RunLoop().Run()
 x.RunUntilIdle()     RunLoop().RunUntilIdle()

x->Run()              RunLoop().Run()
x->RunUntilIdle()     RunLoop().RunUntilIdle()
    If |x| isn't MessageLoopForUI::current() or
    MessageLoopForIO::current()
----------------------------------------------------------

|x| is a base::MessageLoop(ForUI|ForIO) or a pointer to
a base::MessageLoop(ForUI|ForIO).

This CL was generated using the MessageLoopDeprecatedMethods
clang-tidy fix available on the associated bug. Only files
that compile on Mac are affected. Follow-up CLs will make
these replacements for other platforms.

This CL doesn't change code behavior.

TBR=garykac@chromium.org
BUG=616447
==========

[commit-bot: I haz the power, 2016-07-04 21:57:00]

Committed patchset #5 (id:80001)

[commit-bot: I haz the power, 2016-07-04 21:58:34]

Description was changed from

==========
Remove remaining calls to deprecated MessageLoop methods.

This CL makes the following replacements everywhere:

Before               After
----------------------------------------------------------
 x.PostTask()          x.task_runner()->PostTask()
   PostDelayedTask()                    PostDelayedTask()
   ReleaseSoon()                        ReleaseSoon()
   DeleteSoon()                         DeleteSoon()

x->PostTask()         y->task_runner()->PostTask()
   PostDelayedTask()                    PostDelayedTask()
   ReleaseSoon()                        ReleaseSoon()
   DeleteSoon()                         DeleteSoon()

 x.Run()              RunLoop().Run()
 x.RunUntilIdle()     RunLoop().RunUntilIdle()

x->Run()              RunLoop().Run()
x->RunUntilIdle()     RunLoop().RunUntilIdle()
    If |x| isn't MessageLoopForUI::current() or
    MessageLoopForIO::current()
----------------------------------------------------------

|x| is a base::MessageLoop(ForUI|ForIO) or a pointer to
a base::MessageLoop(ForUI|ForIO).

This CL was generated using the MessageLoopDeprecatedMethods
clang-tidy fix available on the associated bug. Only files
that compile on Mac are affected. Follow-up CLs will make
these replacements for other platforms.

This CL doesn't change code behavior.

TBR=garykac@chromium.org
BUG=616447
==========

to

==========
Remove remaining calls to deprecated MessageLoop methods.

This CL makes the following replacements everywhere:

Before               After
----------------------------------------------------------
 x.PostTask()          x.task_runner()->PostTask()
   PostDelayedTask()                    PostDelayedTask()
   ReleaseSoon()                        ReleaseSoon()
   DeleteSoon()                         DeleteSoon()

x->PostTask()         y->task_runner()->PostTask()
   PostDelayedTask()                    PostDelayedTask()
   ReleaseSoon()                        ReleaseSoon()
   DeleteSoon()                         DeleteSoon()

 x.Run()              RunLoop().Run()
 x.RunUntilIdle()     RunLoop().RunUntilIdle()

x->Run()              RunLoop().Run()
x->RunUntilIdle()     RunLoop().RunUntilIdle()
    If |x| isn't MessageLoopForUI::current() or
    MessageLoopForIO::current()
----------------------------------------------------------

|x| is a base::MessageLoop(ForUI|ForIO) or a pointer to
a base::MessageLoop(ForUI|ForIO).

This CL was generated using the MessageLoopDeprecatedMethods
clang-tidy fix available on the associated bug. Only files
that compile on Mac are affected. Follow-up CLs will make
these replacements for other platforms.

This CL doesn't change code behavior.

TBR=garykac@chromium.org
BUG=616447

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

[commit-bot: I haz the power, 2016-07-04 21:58:37]

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