Bug 142349

Summary: Use std::unique_ptr instead of PassOwnPtr|OwnPtr for ResourceRequest
Product: WebKit Reporter: Joonghun Park <jh718.park>
Component: WebCore Misc.Assignee: Nobody <webkit-unassigned>
Status: RESOLVED FIXED    
Severity: Normal CC: achristensen, bfulgham, commit-queue, darin, gyuyoung.kim, ossy, peavo
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: Unspecified   
OS: Unspecified   
Bug Depends on:    
Bug Blocks: 128007    
Attachments:
Description Flags
Patch
none
Patch none

Description Joonghun Park 2015-03-05 09:51:44 PST
Change from PassOwnPtr|OwnPtr to std::unique_ptr for ResourceRequest in All ports.
Comment 1 Joonghun Park 2015-03-05 09:54:18 PST
Created attachment 247959 [details]
Patch
Comment 2 Darin Adler 2015-03-05 11:42:00 PST
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.
Comment 3 Joonghun Park 2015-03-05 12:10:04 PST
Created attachment 247976 [details]
Patch
Comment 4 Joonghun Park 2015-03-05 12:20:12 PST
(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. :)
Comment 5 Gyuyoung Kim 2015-03-05 18:20:11 PST
(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.
Comment 6 Joonghun Park 2015-03-05 19:27:19 PST
Ok, I will do it.
Comment 7 WebKit Commit Bot 2015-03-05 20:49:34 PST
Comment on attachment 247976 [details]
Patch

Clearing flags on attachment: 247976

Committed r181136: <http://trac.webkit.org/changeset/181136>
Comment 8 WebKit Commit Bot 2015-03-05 20:49:38 PST
All reviewed patches have been landed.  Closing bug.
Comment 9 Csaba Osztrogonác 2015-03-06 02:26:42 PST
(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.
Comment 10 Gyuyoung Kim 2015-03-06 03:15:52 PST
(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.