Use nullptr_t for RefPtr, PassRefPtr and RawPtr.

Use nullptr_t for RefPtr, PassRefPtr and RawPtr.

This makes all of our smart pointers use nullptr_t to avoid issues when
using the oilpan transition types where we get a mix of nullptr and 0
that does not work unless we make OwnPtr, RefPtr, PassRefPtr consistently
use one or the other. Since we have decided to use nullptr for OwnPtr
(which used to use 0) this change goes all out and uses nullptr
consistently for all of them.

R=eseidel@chromium.org, haraken@chromium.org, wibling@chromium.org, abarth@chromium.org, jochen@chromium.org

Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=167578

[Mads Ager (chromium), 2014-02-18 16:27:14]

This is to avoid issues when using the oilpan transition types where we get a
mix of nullptr and 0 that does not work unless we make OwnPtr, RefPtr,
PassRefPtr consistently use one or the other. Since we have decided to use
nullptr for OwnPtr (which used to use 0) this change goes all out and uses
nullptr consistently for all of them.

[eseidel, 2014-02-18 18:44:59]

You oilpan folks are gonna end up owning WTF if you're not careful.

LGTM.

Please fill in BUG= or remove it.

[Mikhail, 2014-02-18 22:35:50]

On 2014/02/18 16:27:14, Mads Ager (chromium) wrote:
> This is to avoid issues when using the oilpan transition types where we get a
> mix of nullptr and 0 that does not work unless we make OwnPtr, RefPtr,
> PassRefPtr consistently use one or the other. Since we have decided to use
> nullptr for OwnPtr (which used to use 0) this change goes all out and uses
> nullptr consistently for all of them.

IMO if we had a real C++11 nullptr there would not be any issues, since real
nullptr
can convert to any pointer type. Maybe instead, we could just teach our
home-brewed
nullptr to do the same and then just use it consistently (for both smart&plain
pointers)
in the client code? Pls. consider the following 
(based on http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2431.pdf)

class WTF_EXPORT_PRIVATE nullptr_t {
 public:
     template<class T>
     operator T*() const { return 0; }
     template<class C, class T>
     operator T C::*() const { return 0; }
 private:
     void operator&() const;
 };

Benefits of this approach:
1) no need to add  'nullptr_t' constructors to Pass/RefPtr
2) Looks like we can remove

#if !COMPILER_SUPPORTS(CXX_NULLPTR)
        RefPtr& operator=(std::nullptr_t) { clear(); return *this; }
#endif

from RefPtr as well
3) Makes our 'nullptr' closer to the standard behavior, allows using it further
even with plain pointers -> gain even more consistency

wdyt?

[haraken, 2014-02-19 00:29:10]

LGTM. Add a bit more background to the CL description.

[Mads Ager (chromium), 2014-02-19 06:49:43]

On 2014/02/18 22:35:50, mikhail.pozdnyakov wrote:
> On 2014/02/18 16:27:14, Mads Ager (chromium) wrote:
> > This is to avoid issues when using the oilpan transition types where we get
a
> > mix of nullptr and 0 that does not work unless we make OwnPtr, RefPtr,
> > PassRefPtr consistently use one or the other. Since we have decided to use
> > nullptr for OwnPtr (which used to use 0) this change goes all out and uses
> > nullptr consistently for all of them.
> 
> IMO if we had a real C++11 nullptr there would not be any issues, since real
> nullptr
> can convert to any pointer type. Maybe instead, we could just teach our
> home-brewed
> nullptr to do the same and then just use it consistently (for both smart&plain
> pointers)
> in the client code? Pls. consider the following 
> (based on http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2431.pdf)
> 
> class WTF_EXPORT_PRIVATE nullptr_t {
>  public:
>      template<class T>
>      operator T*() const { return 0; }
>      template<class C, class T>
>      operator T C::*() const { return 0; }
>  private:
>      void operator&() const;
>  };
> 
> Benefits of this approach:
> 1) no need to add  'nullptr_t' constructors to Pass/RefPtr
> 2) Looks like we can remove
> 
> #if !COMPILER_SUPPORTS(CXX_NULLPTR)
>         RefPtr& operator=(std::nullptr_t) { clear(); return *this; }
> #endif
> 
> from RefPtr as well
> 3) Makes our 'nullptr' closer to the standard behavior, allows using it
further
> even with plain pointers -> gain even more consistency
> 
> wdyt?

I think that sounds good and it can be done as a smaller followup to this
change. It is true that our home-brewed nullptr is what is causing the issues.
The upside to this changelist is that we get all the '0' occurrences for RefPtr
and PassRefPtr replaced by nullptr throughout the code base. :-)

[Mads Ager (chromium), 2014-02-19 08:36:22]

The CQ bit was checked by ager@chromium.org

[commit-bot: I haz the power, 2014-02-19 08:36:47]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/ager@chromium.org/170603003/250001

[wibling-chromium, 2014-02-19 08:42:45]

lgtm

[commit-bot: I haz the power, 2014-02-19 11:08:07]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2014-02-19 11:08:08]

Retried try job too often on win_blink_rel for step(s) webkit_tests
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=win_blink_...

[Mads Ager (chromium), 2014-02-19 17:28:20]

The CQ bit was checked by ager@chromium.org

[commit-bot: I haz the power, 2014-02-19 21:50:23]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/ager@chromium.org/170603003/410001

[commit-bot: I haz the power, 2014-02-19 22:56:19]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/ager@chromium.org/170603003/410001

[commit-bot: I haz the power, 2014-02-19 22:58:32]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2014-02-19 22:58:32]

Failed to request the patch to try. Please note that binary files are still
unsupported at the moment, this is being worked on.

Thanks for your patience.

<urlopen error [Errno 110] Connection timed out>

[Mads Ager (chromium), 2014-02-21 07:36:31]

Committed patchset #11 manually as r167578 (tree was closed).

[haraken, 2014-02-21 09:39:25]

On 2014/02/21 07:36:31, Mads Ager (chromium) wrote:
> Committed patchset #11 manually as r167578 (tree was closed).

Looks like this commit was a success :)

Now you might want to announce to blink-dev that we need to use nullptr for
RefPtr from now.