Update {virtual,override,final} for components/ to follow C++11 style.

components/policy/core/common/policy_loader_mac_unittest.cc

 // Copyright (c) 2012 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 <CoreFoundation/CoreFoundation.h>
 
 #include "base/basictypes.h"
 #include "base/callback.h"
 #include "base/files/file_path.h"
 #include "base/mac/scoped_cftyperef.h"
@@ skipping 119 matching lines @@
     testing::Values(TestHarness::Create));
 
 // TODO(joaodasilva): instantiate Configuration3rdPartyPolicyProviderTest too
 // once the mac loader supports 3rd party policy. http://crbug.com/108995
 
 // Special test cases for some mac preferences details.
 class PolicyLoaderMacTest : public PolicyTestBase {
  protected:
   PolicyLoaderMacTest()
       : prefs_(new MockPreferences()) {}
-  virtual ~PolicyLoaderMacTest() {}

[erikwright (departed), 2015/01/09 21:06:51]

Chromium guidelines encourage consistent declaration of destructors for all
non-POD objects, even when declared in a .cc file.

http://www.chromium.org/developers/coding-style/cpp-dos-and-donts#TOC-When-yo....

[dcheng, 2015/01/09 22:09:32]

The reason we declare them is so we can define them out-of-line, to potentially
avoid destructor bloat. This declaration is inline as it is, so there is no
difference between explicitly declaring it and letting the compiler emit an
implicit one.

[Mattias Nissler (ping if slow), 2015/01/13 10:03:13]

The reason this dtor is here is actually because the rule is all classes with
virtual functions should have a virtual dtor. We often waive that rule for
tests. I don't feel strong on this.

[erikwright (departed), 2015/01/13 12:03:27]

I re-read C++ Dos and Don'ts, "What about code outside of headers?":

"it's still wise to follow the above guidelines... Being in a consistent habit
everywhere reduces the risk of making mistakes, and results in more consistent
code... "

Which is what I had based my earlier comment on. But then I kept reading:

"For testing code, most of these factors are reduced or eliminated ...
Ultimately, test file inlining should be a readability-focused judgment call on
the part of the test author and reviewer."

Which seems to apply to this case.

 
-  virtual void SetUp() override {
+  void SetUp() override {
     PolicyTestBase::SetUp();
     scoped_ptr<AsyncPolicyLoader> loader(new PolicyLoaderMac(
         loop_.message_loop_proxy(), base::FilePath(), prefs_));
     provider_.reset(new AsyncPolicyProvider(&schema_registry_, loader.Pass()));
     provider_->Init(&schema_registry_);
   }
 
-  virtual void TearDown() override {
+  void TearDown() override {
     provider_->Shutdown();
     PolicyTestBase::TearDown();
   }
 
   MockPreferences* prefs_;
   scoped_ptr<AsyncPolicyProvider> provider_;
 };
 
 TEST_F(PolicyLoaderMacTest, Invalid) {
   ScopedCFTypeRef<CFStringRef> name(
@@ skipping 29 matching lines @@
   expected_bundle.Get(PolicyNamespace(POLICY_DOMAIN_CHROME, std::string()))
       .Set(test_keys::kKeyString,
            POLICY_LEVEL_RECOMMENDED,
            POLICY_SCOPE_USER,
            new base::StringValue("string value"),
            NULL);
   EXPECT_TRUE(provider_->policies().Equals(expected_bundle));
 }
 
 }  // namespace policy