NEW 109162
[WebKit2] Switch back to assigning std::nullptr to the ChildProcessProxy pointer in DownloadProxyMap 
https://bugs.webkit.org/show_bug.cgi?id=109162
Summary [WebKit2] Switch back to assigning std::nullptr to the ChildProcessProxy poin...
Zan Dobersek
Reported 2013-02-07 02:45:38 PST
[WebKit2] Switch back to assigning std::nullptr to the ChildProcessProxy pointer in DownloadProxyMap
Attachments
Patch (1.69 KB, patch)
2013-02-07 02:47 PST, Zan Dobersek 		darin: review+
webkit-ews: commit-queue-
DetailsFormatted DiffDiff
View All Add attachment proposed patch, testcase, etc.
Zan Dobersek
Comment 1 2013-02-07 02:47:15 PST
Created attachment 187033 [details] Patch
Zan Dobersek
Comment 2 2013-02-07 02:48:50 PST
Here's the patch, I'm running a local build but I guess it would make sense to wait for the qt-wk2 and mac-wk2 EWSs to report the patch validity.
Early Warning System Bot
Comment 3 2013-02-07 02:52:30 PST
Comment on attachment 187033 [details] Patch Attachment 187033 [details] did not pass qt-wk2-ews (qt): Output: http://queues.webkit.org/results/16408189
EFL EWS Bot
Comment 4 2013-02-07 03:14:20 PST
Comment on attachment 187033 [details] Patch Attachment 187033 [details] did not pass efl-ews (efl): Output: http://queues.webkit.org/results/16428084
Zan Dobersek
Comment 5 2013-02-07 04:12:28 PST
Looking from the current uses of assigning nullptr, it seems as it's only ever assigned to a pointer encapsulated by OwnPtr or RefPtr. The m_process variable is in this case a bare pointer.
Build Bot
Comment 6 2013-02-07 07:37:52 PST
Comment on attachment 187033 [details] Patch Attachment 187033 [details] did not pass win-ews (win): Output: http://queues.webkit.org/results/16443159
Darin Adler
Comment 7 2013-02-08 09:55:50 PST
Comment on attachment 187033 [details] Patch Change seems good in theory. Not sure why the EWS bots are showing build failures, though. Please don’t land the change if it’s going to break the build on a platform where it was working.
Zan Dobersek
Comment 8 2013-03-18 07:37:33 PDT
The problem here is that the dummy std::nullptr_t implementation in Source/WTF/wtf/NullPtr.h only works when assigning nullptr to a smart pointer but fails to compile when assigning it to a non-smart pointer (as is the case in this patch). There are obviously still ports that require that dummy implementation, in the meantime the GTK port now limits the set of supported compilers so std:nullptr_t support is now provided by the compiler.
Note You need to log in before you can comment on or make changes to this bug.