add a user-provided constructor to emulated c++11 NullPtr

add a user-provided constructor to emulated c++11 NullPtr

According to this GCC bug/patch, a user-specified constructor is
required for the emulated C++11 nullptr_t class if we want to be able
to create const nullptr_t objects without an explicit initializer,
a la: "const std::nullptr_t nullptr;"

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42844

This fixes a build failure in GCC 4.5.

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

[Mostyn Bramley-Moore, 2014-06-09 22:23:29]

@Sigbjørn, Mads: PTAL at this small fixup.

@Benjamin: can you see if this works for you?

[Peter Kasting, 2014-06-09 23:07:00]

Drive-by

https://codereview.chromium.org/322913002/diff/1/Source/wtf/NullPtr.h
File Source/wtf/NullPtr.h (right):

https://codereview.chromium.org/322913002/diff/1/Source/wtf/NullPtr.h#newcode52
Source/wtf/NullPtr.h:52: // Required to create uninitialized const nullptr's.
Nit: Do not use an apostrophe to make something plural.

Consider an example of an "uninitialized const nullptr", as I consider myself
reasonably knowledgable about C++ and have trouble parsing that.

[Mostyn Bramley-Moore, 2014-06-09 23:33:30]

https://codereview.chromium.org/322913002/diff/1/Source/wtf/NullPtr.h
File Source/wtf/NullPtr.h (right):

https://codereview.chromium.org/322913002/diff/1/Source/wtf/NullPtr.h#newcode52
Source/wtf/NullPtr.h:52: // Required to create uninitialized const nullptr's.
On 2014/06/09 23:07:00, Peter Kasting wrote:
> Nit: Do not use an apostrophe to make something plural.
> 
> Consider an example of an "uninitialized const nullptr", as I consider myself
> reasonably knowledgable about C++ and have trouble parsing that.

Rephrased to avoid the apostrophe, hopefully it's a bit more readable now.

[Peter Kasting, 2014-06-09 23:36:56]

On 2014/06/09 23:33:30, Mostyn Bramley-Moore wrote:
> https://codereview.chromium.org/322913002/diff/1/Source/wtf/NullPtr.h
> File Source/wtf/NullPtr.h (right):
> 
>
https://codereview.chromium.org/322913002/diff/1/Source/wtf/NullPtr.h#newcode52
> Source/wtf/NullPtr.h:52: // Required to create uninitialized const nullptr's.
> On 2014/06/09 23:07:00, Peter Kasting wrote:
> > Nit: Do not use an apostrophe to make something plural.
> > 
> > Consider an example of an "uninitialized const nullptr", as I consider
myself
> > reasonably knowledgable about C++ and have trouble parsing that.
> 
> Rephrased to avoid the apostrophe, hopefully it's a bit more readable now.

Hmm, doesn't seem any clearer.  Do you mean this?

  const nullptr_t n;

If so, I suggest making your comment say something like that:

// Required in order to create const nullpt_tr objects without an explicit
initializer, a la:
//
//   const nullptr_t n;

[Mostyn Bramley-Moore, 2014-06-09 23:48:51]

On 2014/06/09 23:36:56, Peter Kasting wrote:
> > Rephrased to avoid the apostrophe, hopefully it's a bit more readable now.
> 
> Hmm, doesn't seem any clearer.  Do you mean this?
> 
>   const nullptr_t n;
> 
> If so, I suggest making your comment say something like that:
> 
> // Required in order to create const nullpt_tr objects without an explicit
> initializer, a la:
> //
> //   const nullptr_t n;

Done (but used the actual example from NullPtr.cpp).

[Mads Ager (chromium), 2014-06-10 06:08:39]

LGTM, but you will need an OWNER to sign off on the change. Added Erik and
Mikhail as reviewers.

[Mikhail, 2014-06-10 07:15:24]

https://codereview.chromium.org/322913002/diff/40001/Source/wtf/NullPtr.h
File Source/wtf/NullPtr.h (right):

https://codereview.chromium.org/322913002/diff/40001/Source/wtf/NullPtr.h#new...
Source/wtf/NullPtr.h:53: // explicit initializer, a la:
As I see at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42844 there is a
condition that "the object is of (possibly cv-qualified) non-POD class type",
nullptr_t should not be the case, right?
This is more like a GCC 4.5 particularity, could you pls add to the comment that
this is actually a build fix for GCC 4.5?

[Mostyn Bramley-Moore, 2014-06-10 07:33:58]

https://codereview.chromium.org/322913002/diff/40001/Source/wtf/NullPtr.h
File Source/wtf/NullPtr.h (right):

https://codereview.chromium.org/322913002/diff/40001/Source/wtf/NullPtr.h#new...
Source/wtf/NullPtr.h:53: // explicit initializer, a la:
On 2014/06/10 07:15:24, mikhail.pozdnyakov wrote:
> As I see at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42844 there is a
> condition that "the object is of (possibly cv-qualified) non-POD class type",
> nullptr_t should not be the case, right?

I think the second clause matches here (not the first that you quoted):
"if the object is of const-qualified type, the underlying class type shall have
a user-declared default constructor."

> This is more like a GCC 4.5 particularity, could you pls add to the comment
that
> this is actually a build fix for GCC 4.5?

Done.

[Mikhail, 2014-06-10 07:49:16]

lgtm

[Mostyn Bramley-Moore, 2014-06-10 07:50:01]

The CQ bit was checked by mostynb@opera.com

[commit-bot: I haz the power, 2014-06-10 07:50:38]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/mostynb@opera.com/322913002/60001

[bedupontcisco_gmail.com, 2014-06-10 07:55:12]

On 2014/06/09 22:23:29, Mostyn Bramley-Moore wrote:
> @Sigbjørn, Mads: PTAL at this small fixup.
> 
> @Benjamin: can you see if this works for you?

Yes it works with our toolchain.

Thanks.

[commit-bot: I haz the power, 2014-06-10 08:58:34]

Change committed as 175874