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

[Greg Clayton]

On Jun 26, 2013, at 2:38 PM, Eric Christopher <echristo at gmail.com> wrote:

>>> 
>>> The short answer is that DW_TAG_unspecified_type can be used for more
>>> than just nullptr_t.
>> 
>> So shouldn't the function be called createUnspecifiedType (possibly
>> with a createNullPtrType convenience function)?
>> 
> 
> Yep. Feel free to make this change. (Don't worry about
> createNullPtrType unless you really want it).
> 
>>> The long answer is:
>>> 
>>> "An unspecified (implicit, unknown, ambiguous or nonexistent) type is
>>> represented by a debugging information entry with the tag
>>> DW_TAG_unspecified_type. If a name has been given to the type, then
>>> the corresponding unspecified type entry has a DW_AT_name attribute
>>> whose value is a null-terminated string containing the name as it
>>> appears in the source program. The interpretation of this debugging
>>> information entry is intentionally left flexible to allow it to be
>>> interpreted appropriately in different languages. For example, in C
>>> and C++ the language implementation can provide an unspecified type
>>> entry with the name “void” which can be referenced by the type
>>> attribute of pointer types and typedef declarations for 'void' (see
>>> Sections 0 and 5.3, respectively). As another example, in Ada such an
>>> unspecified type entry can be referred to by the type attribute of an
>>> access type where the denoted type is incomplete (the name is declared
>>> as a type but the definition is deferred to a separate compilation
>>> unit)."
>> 
>> 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.  And it looks like LLDB only recognises
>> the "nullptr_t" name [2].  What a mess.  Would changing Clang (and
>> DragonEgg) to use "decltype(nullptr)", and making LLDB recognise it
>> as well, present too many compatibility issues?
>> 
> 
> Sounds good to me.
> 
> Greg: Would you mind handling this on the LLDB end please?
> 
% svn diff
Index: source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
===================================================================
--- source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp	(revision 185381)
+++ source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp	(working copy)
@@ -5740,7 +5740,8 @@
                         break;
 
                     case DW_TAG_unspecified_type:
-                        if (strcmp(type_name_cstr, "nullptr_t") == 0)
+                        if (strcmp(type_name_cstr, "nullptr_t") == 0 ||
+                            strcmp(type_name_cstr, "decltype(nullptr)") == 0 )
                         {
                             resolve_state = Type::eResolveStateFull;
                             clang_type = ast.getASTContext()->NullPtrTy.getAsOpaquePtr();
% svn commit
Sending        source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
Transmitting file data .
Committed revision 185382.