[Lldb-commits] [lldb] r282648 - Fix an issue where libc++ changed the type information we get for std::map::iterator, rendering LLDB unable to display elements vended by an iterator

[Enrico Granata via lldb-commits]

> On Sep 29, 2016, at 10:50 AM, Zachary Turner <zturner at google.com> wrote:
> 
> 
> 
> On Thu, Sep 29, 2016 at 10:43 AM Enrico Granata <egranata at apple.com <mailto:egranata at apple.com>> wrote:
>> On Sep 28, 2016, at 5:58 PM, Zachary Turner <zturner at google.com <mailto:zturner at google.com>> wrote:
>> 
>> 
>> 
>> On Wed, Sep 28, 2016 at 4:02 PM Enrico Granata via lldb-commits <lldb-commits at lists.llvm.org <mailto:lldb-commits at lists.llvm.org>> wrote:
>> 
>> -
>> +
>> +  static ConstString g___i_("__i_");
>> +
>>    // this must be a ValueObject* because it is a child of the ValueObject we are
>>    // producing children for
>>    // it if were a ValueObjectSP, we would end up with a loop (iterator ->
>> @@ -281,6 +287,57 @@ bool lldb_private::formatters::LibCxxMap
>>                                     SyntheticChildrenTraversal::None),
>>                         nullptr)
>>                     .get();
>> +
>> +  if (!m_pair_ptr) {
>> +    m_pair_ptr = valobj_sp->GetValueForExpressionPath(".__i_.__ptr_", nullptr, nullptr, nullptr,
>> +                                                      ValueObject::GetValueForExpressionPathOptions()
>> +                                                      .DontCheckDotVsArrowSyntax()
>> +                                                      .SetSyntheticChildrenTraversal(
>> +                                                                                     ValueObject::GetValueForExpressionPathOptions::
>> +                                                                                     SyntheticChildrenTraversal::None),
>> +                                                      nullptr)
>> +    .get();
>> +    if (m_pair_ptr) {
>> +      auto __i_(valobj_sp->GetChildMemberWithName(g___i_, true));
>> Is there any reason we need to use such weird variable names?  This looks like undefined behavior to me.  Variables with more than one adjacent underscore are reserved.
> 
> I am naming the variable the same as the corresponding variable in the type I am formatting. Future me is usually thankful when I do that.. it helps keep track of what ValueObject matches what child element; in this case, our iterators have an __i_ child
> 
> Ahh, makes sense.  Unfortunately at least in this case it leads to illegal variable names.  Is there anything else it could be named that would be similar enough to help remembering but a valid c++ identifier?

Sure, we just add a "vo" prefix, like vo__i_

I thought the rule about __ being magic only applied to global identifiers, and I have never seen any compiler complain about those identifiers in practice. But reserved is reserved, so thanks for pointing that out.

Thanks,
- Enrico
📩 egranata@.com ☎️ 27683

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-commits/attachments/20160929/87c50f36/attachment.html>