[C++0x] nullptr

[Jason Merrill]

On 03/14/2010 12:56 AM, Magnus Fromreide wrote:
> First, I am not certain about how
>
>    foo(char*)
>    foo(decltype(nullptr))
>    void f() { foo(0); }
>
> should be handled - Looking at n3035 I think i should be ambiguous but
> that feels very odd. If someone could help me understand this I would be
> happy.

Conversion from 0 to nullptr_t is a pointer conversion, just as 
conversion to char*.  The goal of introducing nullptr is to allow us to 
use something better than 0 as the argument.

> Secondly, I have choosen to call the type that results from
> decltype(nullptr) 'std::nullptr_t' in order to make the error messages
> more readable - I am uncertain of this decision though, would it be
> better to call it 'decltype(nullptr)'?

I think use std::nullptr_t.

> Thirdly, in the test suite nullptr19.C fails due to excess errors, I do
> not know how to make it not fail as I think it looks like I have told
> deja-gnus about all the errors that I expect.

> +//  type_equal<nullptr_t>(k(__null)); /* { dg-error "is ambiguous" } */

Is this line supposed to be commented out?  It won't get an error that way.

> Index: gcc/testsuite/g++.dg/cpp0x/nullptr09.C
> +  if( nullptr == 0 );  // { dg-error "invalid operands of types " }

This is well-formed; the composite pointer type here is nullptr_t, which 
will be clearer in the forthcoming FCD.  See
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#963

> +// Test aritmetic operations

"arithmetic"

> +      else if (code0 == NULLPTR_TYPE && code1 == NULLPTR_TYPE)
> +        {
> +          if (code == EQ_EXPR)
> +            result_type = type1;
> +          else
> +            result_type = type0;
> +        }

It seems that you expect type1 and type0 to encode boolean true and 
false, which they don't.  Both of them will be nullptr_t.  And the same 
comment for the next hunk.

> +      if (TREE_CODE (intype) == NULLPTR_TYPE)
> +        return build_int_cst (type, 0);

Why not fall through to cp_convert in this case?

> +      tree nullptr_type_node = make_node (NULLPTR_TYPE);
> +      TYPE_SIZE (nullptr_type_node) = bitsize_int (GET_MODE_BITSIZE(ptr_mode));
> +      TYPE_SIZE_UNIT (nullptr_type_node) = size_int (GET_MODE_SIZE(ptr_mode));
> +      TYPE_UNSIGNED (nullptr_type_node) = 1;
> +      TYPE_PRECISION (nullptr_type_node) = GET_MODE_BITSIZE(ptr_mode);
> +      SET_TYPE_MODE (nullptr_type_node, Pmode);
> +      nullptr_node = make_node(INTEGER_CST);
> +      TREE_TYPE (nullptr_node) = nullptr_type_node;

Missing some spaces before (.

> +        tree type = TREE_TYPE (t);
> +        if (type == TREE_TYPE(nullptr_node))
> +          pp_string(pp, "nullptr");
> +        else
> +          pp_c_constant(pp_c_base (pp), t);

Likewise.

> Fourthly, the patch only adds support for nullptr on ELF - I do not know
> neither how to encode it nor in what file to do it on other platforms.
> For ELF i used the proposed extension from
> http://www.codesourcery.com/archives/cxx-abi-dev/msg02159.html as that
> seemed uncontroversial.
> Support for all other object formats is completely missing and so
> triggers ICE's.

Mangling is independent of object file format, the code you add to 
mangle.c should cover all of them.

> Fifthly, the patch don't add support for any debugging format. I have
> seen http://wiki.dwarfstd.org/index.php?title=C%2B%2B0x:_Null_pointer
> but failed to wrap my head around dwarf2out.c. The patch add enough
> support to not trigger an ICE but this is very half baked and so needs
> to be fixed.
> Support for all other debugging formats is completely missing and so
> triggers ICE's.

> +++ gcc/dwarf2out.c	(working copy)
> @@ -12019,6 +12019,7 @@
>      case ENUMERAL_TYPE:
>      case FUNCTION_TYPE:
>      case METHOD_TYPE:
> +    case NULLPTR_TYPE:

Hmm, interesting that this compiles, given that NULLPTR_TYPE is a front 
end tree code.  I hadn't previously noticed the change to make all tree 
codes available from tree.h.

I think you just want something like

dw_die_ref die = new_die (DW_TAG_unspecified_type, comp_unit_die, type);
add_name_attribute (die, "decltype(nullptr)");

I'm not sure how gdb will deal with either decltype(nullptr) or 
std::nullptr_t as names, it might have problems.

> Lastly, I would like to know if the basic idea is viable or if there is
> some extension I missed that would make it even easier to add nullptr
> support.

The compiler changes look good to me apart from the above comments.

Jason