[lldb-dev] How to deal with STL type names in C++ code?

[Siva Chandra via lldb-dev]

On Thu, Aug 6, 2015 at 3:58 PM, Enrico Granata <egranata at apple.com> wrote:

>
> On Aug 6, 2015, at 3:50 PM, Siva Chandra <sivachandra at google.com> wrote:
>
>
>
> On Thu, Aug 6, 2015 at 3:38 PM, Enrico Granata <egranata at apple.com> wrote:
>
>>
>> On Aug 6, 2015, at 3:33 PM, Siva Chandra <sivachandra at google.com> wrote:
>>
>>
>>
>> On Thu, Aug 6, 2015 at 2:43 PM, Enrico Granata <egranata at apple.com>
>> wrote:
>>
>>> To be honest, my favorite approach would be to modify clang’s
>>> TypePrinter to do this, and then hooking up GetDisplayTypeName() to use
>>> whatever flags would be necessary to invoke that bit of magic
>>>
>>
>> Do you mean that clang's "pretty printer" should be made extensible by a
>> script?
>>
>>
>>
>> Nope, what I am imagining is not an extensible system
>>
>> When LLDB goes to print a type it asks the compiler “what is the name of
>> this type that I should display?”
>> By default, clang prints the fully specialized template, including type
>> arguments that have their default value. My theory is that we would want to
>> add a mode to the type printer to say “simplify type name”, and that would
>> do sensible things to get a display name that is more compact
>>
>
> So, how would clang know about the "simplified" or "friendly" name for a
> type? Even in case of standard library types, the underlying types (with
> unfriendly type names) could be anything. For example, libstdc++ and
> STLport have different underlying naming conventions. So does libc++ I
> would imagine (I have not spent enough time yet staring at libc++ code).
>
>
> The obvious mechanism is that the compiler has knowledge of the structure
> of the type - so it can make printing decisions based on that type structure
> In this case, I imagine a viable approach would be having rules like
> omitting the values of template arguments that have a default value, omit
> inlined namespaces, ...
>

OK. I will be on vacation next week. Will give this idea a shot after
getting back.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20150806/fddc1f53/attachment.html>