Change from PassOwnPtr|OwnPtr to std::unique_ptr for ResourceRequest in All ports.
Created attachment 247959 [details] Patch
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.
Created attachment 247976 [details] Patch
(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. :)
(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.
Ok, I will do it.
Comment on attachment 247976 [details] Patch Clearing flags on attachment: 247976 Committed r181136: <http://trac.webkit.org/changeset/181136>
All reviewed patches have been landed. Closing bug.
(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.
(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.