[dragonegg PATCH] Fix debug info for std::nullptr_t

David Blaikie dblaikie at gmail.com
Wed Jun 26 16:24:58 PDT 2013


On Wed, Jun 26, 2013 at 3:46 PM, Peter Collingbourne <peter at pcc.me.uk> wrote:
> On Wed, Jun 26, 2013 at 02:42:49PM -0700, David Blaikie wrote:
>> On Wed, Jun 26, 2013 at 2:35 PM, Peter Collingbourne <peter at pcc.me.uk> wrote:
>> > So the name is left unspecified.  Unsurprisingly, Clang and GCC have
>> > diverged here -- Clang uses "nullptr_t" as the name while GCC uses
>> > "decltype(nullptr)".  A standards proposal of sorts [1] proposes that
>> > "decltype(nullptr)" be used.
>> > [1] http://wiki.dwarfstd.org/index.php?title=C%2B%2B0x:_Null_pointer
>>
>> The proposal (which isn't proposing anything) merely states that "the
>> type of nullptr is decltype(nullptr)" which is true but incomplete,
>> the C++ standard states "The pointer literal is the keyword nullptr.
>> It is a prvalue of type std::nullptr_t." (though I'll admit we
>> probably don't put the nullptr_t type in the std namespace)
>
> It's a badly written proposal.  The actual "proposal" (to use
> "decltype(nullptr)" as the name) is hidden in the "example" section
> (and could possibly be inferred from the other sections and a leap
> of faith).

Yeah, it's not clear which parts of the example are intended to be significant.

> I wouldn't call the proposal incomplete, at least not in the way
> you mention.

Well, more that it didn't propose any change to DWARF, so I'm not sure
what it was really proposing.

> If anything, the standard contains similarly circular
> definitions.  [support.types]p9 defines std::nullptr_t as a typedef
> for decltype(nullptr), which is probably the closest the standard
> gets to a "canonical" type for nullptr (which needn't be in the
> std namespace, or any namespace at all really).  It looks like the
> standard uses std::nullptr_t as a convenient shorthand throughout,
> without needing to talk about the canonical type of nullptr.  So it
> isn't clear why the canonical nullptr type should be in std.

True enough - both Clang & GCC produce the nullptr_t typedef within
the 'std' namespace referring to the unspecified_type with different
names - and the name isn't too important. I'd be OK with that name
being decltype(nullptr), on reflection. Sorry for the confusion &
thanks for the explanation.

(that being said, not a priority for me to go & write that patch - but
happy to accept it (& yeah, renaming that function to
createUnspecifiedType, or removing the parameter & hardcoding the name
seem like reasonable changes too))



More information about the llvm-commits mailing list