Add missing .Pass() on return of SampleVector

Add missing .Pass() on return of SampleVector

On VS2015 without this causes:

d:\src\cr3\src\base\metrics\histogram.cc(372): error C2248: 'scoped_ptr<base::SampleVector,base::DefaultDeleter<T>>::scoped_ptr': cannot access private member declared in class 'scoped_ptr<base::SampleVector,base::DefaultDeleter<T>>'
        with
        [
            T=base::SampleVector
        ]
d:\src\cr3\src\base\memory\scoped_ptr.h(312): note: see declaration of 'scoped_ptr<base::SampleVector,base::DefaultDeleter<T>>::scoped_ptr'
        with
        [
            T=base::SampleVector
        ]

I'm not entirely sure why this doesn't happen on earlier compilers,
I guess something's move-ability changed.

R=isherman@chromium.org
BUG=440500
Committed: https://crrev.com/3bec0ffd9cfd92611182bc0f28e5dbc57f4cbaf1
Cr-Commit-Position: refs/heads/master@{#313378}

[Ilya Sherman, 2015-01-27 21:37:31]

LGTM, thanks.

[Ilya Sherman, 2015-01-27 21:37:36]

The CQ bit was checked by isherman@chromium.org

[commit-bot: I haz the power, 2015-01-27 21:38:24]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/882783002/1

[commit-bot: I haz the power, 2015-01-27 22:24:54]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2015-01-27 22:26:05]

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

[brucedawson, 2015-01-27 22:41:47]

Isn't scoped_ptr supposed to behave like unique_ptr, which is supposed to be
returnable?

http://isocpp.org/blog/2014/09/return-unique-ptr-by-value

This is either a bug in VS 2015 or a bug in our scoped_ptr implementation. I
think adding .Pass() here should be avoided, or done as a purely temporary
measure.

[scottmg, 2015-01-27 22:45:06]

Maybe! I was going based on
https://groups.google.com/a/chromium.org/d/msg/chromium-dev/RTd7rNxHjqk/1WHHv...
but... now that I look at the date, that's kinda old. Let me look into it a
bit.

There's one other instance that I ran across at
https://codereview.chromium.org/883753004/ . I set Ryan as the reviewer for
that one; he's likely to know for sure also.

On Tue, Jan 27, 2015 at 2:41 PM, <brucedawson@chromium.org> wrote:

> Isn't scoped_ptr supposed to behave like unique_ptr, which is supposed to
> be
> returnable?
>
> http://isocpp.org/blog/2014/09/return-unique-ptr-by-value
>
> This is either a bug in VS 2015 or a bug in our scoped_ptr implementation.
> I
> think adding .Pass() here should be avoided, or done as a purely temporary
> measure.
>
>
>
> https://codereview.chromium.org/882783002/
>
> To unsubscribe from this group and stop receiving emails from it, send an
> email to chromium-reviews+unsubscribe@chromium.org.
>

To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[scottmg, 2015-01-27 22:46:22]

It looks like, at least in Chrome, we can only avoid the Pass() for
temporaries: http://www.chromium.org/developers/smart-pointer-guidelines (?)

On Tue, Jan 27, 2015 at 2:45 PM, Scott Graham <scottmg@chromium.org> wrote:

> Maybe! I was going based on
>
https://groups.google.com/a/chromium.org/d/msg/chromium-dev/RTd7rNxHjqk/1WHHv...
> but... now that I look at the date, that's kinda old. Let me look into it a
> bit.
>
> There's one other instance that I ran across at
> https://codereview.chromium.org/883753004/ . I set Ryan as the reviewer
> for that one; he's likely to know for sure also.
>
> On Tue, Jan 27, 2015 at 2:41 PM, <brucedawson@chromium.org> wrote:
>
>> Isn't scoped_ptr supposed to behave like unique_ptr, which is supposed to
>> be
>> returnable?
>>
>> http://isocpp.org/blog/2014/09/return-unique-ptr-by-value
>>
>> This is either a bug in VS 2015 or a bug in our scoped_ptr
>> implementation. I
>> think adding .Pass() here should be avoided, or done as a purely temporary
>> measure.
>>
>>
>>
>> https://codereview.chromium.org/882783002/
>>
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to chromium-reviews+unsubscribe@chromium.org.
>>
>
>

To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[jamesr, 2015-01-28 00:22:58]

On 2015/01/27 22:46:22, scottmg wrote:
> It looks like, at least in Chrome, we can only avoid the Pass() for
> temporaries: http://www.chromium.org/developers/smart-pointer-guidelines (?)
> 

This was necessary when we didn't use real rvalue refs to implement smart
pointers, but we do use them now (just like how we used to have to use PassAs<>
to do type coercions, couldn't use nullptr, etc).  This is an xvalue which
should bind to the rvalue ref c'tor.  Definitely seems like a VS2015 bug.

[scottmg, 2015-01-28 00:34:08]

On 2015/01/28 00:22:58, jamesr wrote:
> On 2015/01/27 22:46:22, scottmg wrote:
> > It looks like, at least in Chrome, we can only avoid the Pass() for
> > temporaries: http://www.chromium.org/developers/smart-pointer-guidelines (?)
> > 
> 
> This was necessary when we didn't use real rvalue refs to implement smart
> pointers, but we do use them now (just like how we used to have to use
PassAs<>
> to do type coercions, couldn't use nullptr, etc).  This is an xvalue which
> should bind to the rvalue ref c'tor.  Definitely seems like a VS2015 bug.

I see, so it's not matching the ctor&&, but should, and then is complaining
because we disable the regular non-move ctor?

[scottmg, 2015-01-28 00:54:02]

On 2015/01/28 00:34:08, scottmg wrote:
> On 2015/01/28 00:22:58, jamesr wrote:
> > On 2015/01/27 22:46:22, scottmg wrote:
> > > It looks like, at least in Chrome, we can only avoid the Pass() for
> > > temporaries: http://www.chromium.org/developers/smart-pointer-guidelines
(?)
> > > 
> > 
> > This was necessary when we didn't use real rvalue refs to implement smart
> > pointers, but we do use them now (just like how we used to have to use
> PassAs<>
> > to do type coercions, couldn't use nullptr, etc).  This is an xvalue which
> > should bind to the rvalue ref c'tor.  Definitely seems like a VS2015 bug.
> 
> I see, so it's not matching the ctor&&, but should, and then is complaining
> because we disable the regular non-move ctor?

Filed https://connect.microsoft.com/VisualStudio/feedback/details/1105046.