Bug 142349 – Use std::unique_ptr instead of PassOwnPtr|OwnPtr for ResourceRequest

• Component: WebCore Misc.
• Status: RESOLVED FIXED

[Joonghun Park]

Change from PassOwnPtr|OwnPtr to std::unique_ptr for ResourceRequest in All ports.

[Joonghun Park]

Created attachment 247959 [details]
Patch

[Darin Adler]

Comment on attachment 247959 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=247959&action=review

> Source/WebCore/loader/WorkerThreadableLoader.cpp:100
> -    CrossThreadResourceRequestData* requestData = request.copyData().leakPtr();
> +    auto requestData = request.copyData().release();
>      StringCapture capturedOutgoingReferrer(outgoingReferrer);
>      m_loaderProxy.postTaskToLoader([this, requestData, options, capturedOutgoingReferrer](ScriptExecutionContext& context) {
>          ASSERT(isMainThread());
>          Document& document = downcast<Document>(context);
>  
> -        OwnPtr<ResourceRequest> request = ResourceRequest::adopt(adoptPtr(requestData));
> +        std::unique_ptr<ResourceRequest> request = ResourceRequest::adopt(std::unique_ptr<CrossThreadResourceRequestData>(requestData));

Is there no way to pass the unique_ptr to the lambda? Here’s a thread about it: <http://stackoverflow.com/questions/8640393/move-capture-in-lambda> and <http://stackoverflow.com/questions/8236521/how-to-capture-a-unique-ptr-into-a-lambda-expression>

This is a case where clarity clearly suffers. It was easy to see how the leakPtr and adoptPtr matched up. It’s not nearly was easy to spot the explicit std::unique_ptr construction and see that it matches up with the release() call. Seems like we should make an adopt function for unique_ptr in WTF so this idiom is more readable. I think C++14 will let us handle this in a cleaner way passing the unique_ptr through the lambda.

[Joonghun Park]

Created attachment 247976 [details]
Patch

[Joonghun Park]

(In reply to comment #2)
> Comment on attachment 247959 [details]
> Patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=247959&action=review
> 
> > Source/WebCore/loader/WorkerThreadableLoader.cpp:100
> > -    CrossThreadResourceRequestData* requestData = request.copyData().leakPtr();
> > +    auto requestData = request.copyData().release();
> >      StringCapture capturedOutgoingReferrer(outgoingReferrer);
> >      m_loaderProxy.postTaskToLoader([this, requestData, options, capturedOutgoingReferrer](ScriptExecutionContext& context) {
> >          ASSERT(isMainThread());
> >          Document& document = downcast<Document>(context);
> >  
> > -        OwnPtr<ResourceRequest> request = ResourceRequest::adopt(adoptPtr(requestData));
> > +        std::unique_ptr<ResourceRequest> request = ResourceRequest::adopt(std::unique_ptr<CrossThreadResourceRequestData>(requestData));
> 
> Is there no way to pass the unique_ptr to the lambda? Here’s a thread about
> it: <http://stackoverflow.com/questions/8640393/move-capture-in-lambda> and
> <http://stackoverflow.com/questions/8236521/how-to-capture-a-unique-ptr-into-
> a-lambda-expression>
> 
> This is a case where clarity clearly suffers. It was easy to see how the
> leakPtr and adoptPtr matched up. It’s not nearly was easy to spot the
> explicit std::unique_ptr construction and see that it matches up with the
> release() call. Seems like we should make an adopt function for unique_ptr
> in WTF so this idiom is more readable. I think C++14 will let us handle this
> in a cleaner way passing the unique_ptr through the lambda.

Thank you for your kind comment! It seems that it is needed for me to see this subject more deeper. :)

[Gyuyoung Kim]

(In reply to comment #2)

> This is a case where clarity clearly suffers. It was easy to see how the
> leakPtr and adoptPtr matched up. It’s not nearly was easy to spot the
> explicit std::unique_ptr construction and see that it matches up with the
> release() call. Seems like we should make an adopt function for unique_ptr
> in WTF so this idiom is more readable. I think C++14 will let us handle this
> in a cleaner way passing the unique_ptr through the lambda.

Joonghun, please file a new bug to support Darin's comment.

[Joonghun Park]

Ok, I will do it.

[WebKit Commit Bot]

Comment on attachment 247976 [details]
Patch

Clearing flags on attachment: 247976

Committed r181136: <http://trac.webkit.org/changeset/181136>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.

[Csaba Osztrogonác]

(In reply to comment #7)
> Comment on attachment 247976 [details]
> Patch
> 
> Clearing flags on attachment: 247976
> 
> Committed r181136: <http://trac.webkit.org/changeset/181136>

It broke the WinCairo build: 
https://build.webkit.org/builders/WinCairo%2064-Bit%20Release/builds/44505

cc-ing WinCairo maintainers.

[Gyuyoung Kim]

(In reply to comment #9)
> (In reply to comment #7)
> > Comment on attachment 247976 [details]
> > Patch
> > 
> > Clearing flags on attachment: 247976
> > 
> > Committed r181136: <http://trac.webkit.org/changeset/181136>
> 
> It broke the WinCairo build: 
> https://build.webkit.org/builders/WinCairo%2064-Bit%20Release/builds/44505
> 
> cc-ing WinCairo maintainers.

Speculative build fix in http://trac.webkit.org/changeset/181151.