Remove calls to deprecated MessageLoop methods in tools.

tools/gn/loader_unittest.cc

 // Copyright (c) 2013 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #include <map>
 #include <utility>
 #include <vector>
 
 #include "base/bind.h"
 #include "base/message_loop/message_loop.h"
+#include "base/run_loop.h"
 #include "testing/gtest/include/gtest/gtest.h"
 #include "tools/gn/build_settings.h"
 #include "tools/gn/err.h"
 #include "tools/gn/loader.h"
 #include "tools/gn/parse_tree.h"
 #include "tools/gn/parser.h"
 #include "tools/gn/scheduler.h"
 #include "tools/gn/tokenizer.h"
 
 namespace {
@@ skipping 118 matching lines @@
   loader->set_async_load_file(mock_ifm_.GetCallback());
 
   // Request the root build file be loaded. This should kick off the default
   // build config loading.
   SourceFile root_build("//BUILD.gn");
   loader->Load(root_build, LocationRange(), Label());
   EXPECT_TRUE(mock_ifm_.HasOnePending(build_config));
 
   // Completing the build config load should kick off the root build file load.
   mock_ifm_.IssueAllPending();
-  scheduler_.main_loop()->RunUntilIdle();
+  base::RunLoop().RunUntilIdle();

[Nico, 2016/06/22 18:22:28]

(this replacement looks like it makes things more singleton-y and seems like a
step back to me)

[fdoray, 2016/06/22 18:41:50]

Ironically, a goal of base::RunLoop is to make things less singleton-y.

Currently, the last call to MessageLoop::Run on the thread can be exited by
calling MessageLoop::current()->QuitNow/QuitWhenIdle.

On the other hand, to call RunLoop::Quit/QuitWhenIdle, you need a pointer to a
RunLoop (i.e. you must know which RunLoop you exit and the owned of the RunLoop
must have allowed you to do that).

Using RunLoop makes code more base/task_scheduler friendly (doesn't assume that
it is running on a MessageLoop). Maybe having a base::RunLoop constructor that
takes a MessageLoop as argument (and DCHECK_EQ(base::MessageLoop::current,
message_loop) would make things less singleton-y?

Note that scheduler_.main_loop()->RunUntilIdle(); is extremely misleading! It
runs the current thread's MessageLoop, not necessarily scheduler_.main_loop()
(see
https://cs.chromium.org/chromium/src/base/message_loop/message_loop.cc?sq=pac...)

   EXPECT_TRUE(mock_ifm_.HasOnePending(root_build));
 
   // Load the root build file.
   mock_ifm_.IssueAllPending();
-  scheduler_.main_loop()->RunUntilIdle();
+  base::RunLoop().RunUntilIdle();
 
   // Schedule some other file to load in another toolchain.
   Label second_tc(SourceDir("//tc2/"), "tc2");
   SourceFile second_file("//foo/BUILD.gn");
   loader->Load(second_file, LocationRange(), second_tc);
   EXPECT_TRUE(mock_ifm_.HasOnePending(SourceFile("//tc2/BUILD.gn")));
 
   // Running the toolchain file should schedule the build config file to load
   // for that toolchain.
   mock_ifm_.IssueAllPending();
-  scheduler_.main_loop()->RunUntilIdle();
+  base::RunLoop().RunUntilIdle();
 
   // We have to tell it we have a toolchain definition now (normally the
   // builder would do this).
   const Settings* default_settings = loader->GetToolchainSettings(Label());
   Toolchain second_tc_object(default_settings, second_tc);
   loader->ToolchainLoaded(&second_tc_object);
   EXPECT_TRUE(mock_ifm_.HasOnePending(build_config));
 
   // Scheduling a second file to load in that toolchain should not make it
   // pending yet (it's waiting for the build config).
   SourceFile third_file("//bar/BUILD.gn");
   loader->Load(third_file, LocationRange(), second_tc);
   EXPECT_TRUE(mock_ifm_.HasOnePending(build_config));
 
   // Running the build config file should make our third file pending.
   mock_ifm_.IssueAllPending();
-  scheduler_.main_loop()->RunUntilIdle();
+  base::RunLoop().RunUntilIdle();
   EXPECT_TRUE(mock_ifm_.HasTwoPending(second_file, third_file));
 
   EXPECT_FALSE(scheduler_.is_failed());
 }