Convert Pass()→std::move() on Windows

chrome/browser/ui/views/status_icons/status_tray_state_changer_win.cc

Index: chrome/browser/ui/views/status_icons/status_tray_state_changer_win.cc
diff --git a/chrome/browser/ui/views/status_icons/status_tray_state_changer_win.cc b/chrome/browser/ui/views/status_icons/status_tray_state_changer_win.cc
index 053ac9a0fe4f3756c0c627db32371e765a3e4e51..4596efa36307b09dbc44af1432d58d35a8b9da3c 100644
--- a/chrome/browser/ui/views/status_icons/status_tray_state_changer_win.cc
+++ b/chrome/browser/ui/views/status_icons/status_tray_state_changer_win.cc
@@ -4,6 +4,8 @@
 
 #include "chrome/browser/ui/views/status_icons/status_tray_state_changer_win.h"
 
+#include <utility>
+
 namespace {
 
 ////////////////////////////////////////////////////////////////////////////////
@@ -78,7 +80,7 @@ void StatusTrayStateChangerWin::EnsureTrayIconVisible() {
 
   notify_item->preference = PREFERENCE_SHOW_ALWAYS;
 
-  SendNotifyItemUpdate(notify_item.Pass());
+  SendNotifyItemUpdate(std::move(notify_item));
 }
 
 STDMETHODIMP_(ULONG) StatusTrayStateChangerWin::AddRef() {
@@ -170,8 +172,8 @@ scoped_ptr<NOTIFYITEM> StatusTrayStateChangerWin::RegisterCallback() {
 
   // Adding an intermediate scoped pointer here so that |notify_item_| is reset
   // to NULL.
-  scoped_ptr<NOTIFYITEM> rv(notify_item_.release());
-  return rv.Pass();
+  scoped_ptr<NOTIFYITEM> rv(std::move(notify_item_));

[brettw, 2016/03/02 19:09:08]

This code is pretty suspicious.

With your change it's equivalent to return std::move(notify_item_) and it will
have the effect of leaving notify_item_ in an undefined state.

I think you want the release() call in there as per the old code to guarantee
the state of the old value.

[mmenke, 2016/03/02 19:13:25]

Interesting...I was told this was fine for scoped_ptrs when I bought this up on
another of dcheng's CLs:  https://codereview.chromium.org/1545233002/ (Post
#12).  If we want to avoid this, I suspect we'll have to revisit a lot of
std::move calls.

[dcheng, 2016/03/02 19:38:31]

In general, you're right: you can't depend on the state of a moved-from object.
From [lib.types.movedfrom/1]:
Unless otherwise specified, such moved-from objects shall be placed in a valid
but unspecified state.

However, std::unique_ptr *is* one of the classes where the moved-from state is
defined. From [unique.ptr/4]:
  Additionally, u can, upon request, transfer ownership to another unique
pointer u2. Upon completion of
  such a transfer, the following postconditions hold:
  — u2.p is equal to the pre-transfer u.p,
  — u.p is equal to nullptr, and
  — if the pre-transfer u.d maintained state, such state has been transferred to
u2.d.

Since we aim for compatibility with std::unique_ptr, scoped_ptr also has the
same behavior.

+  return rv;
 }
 
 bool StatusTrayStateChangerWin::RegisterCallbackWin8() {