Bug 109162 – [WebKit2] Switch back to assigning std::nullptr to the ChildProcessProxy pointer in DownloadProxyMap

• Component: New Bugs
• Status: NEW

[Zan Dobersek]

[WebKit2] Switch back to assigning std::nullptr to the ChildProcessProxy pointer in DownloadProxyMap

[Zan Dobersek]

Created attachment 187033 [details]
Patch

[Zan Dobersek]

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 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 on attachment 187033 [details]
Patch

Attachment 187033 [details] did not pass efl-ews (efl):
Output: http://queues.webkit.org/results/16428084

[Zan Dobersek]

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 on attachment 187033 [details]
Patch

Attachment 187033 [details] did not pass win-ews (win):
Output: http://queues.webkit.org/results/16443159

[Darin Adler]

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]

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.