[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

[Zachary Turner via lldb-commits]

Yea :(  In practice you're right that it might not ever be an issue, but I
know one time I spent quite a long time trying to figure out why I couldn't
create a variable named "unix", so any time I see questionable names it
brings back terrible memories.

On Thu, Sep 29, 2016 at 10:58 AM Enrico Granata <egranata at apple.com> wrote:

>
> 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>
> wrote:
>
> On Sep 28, 2016, at 5:58 PM, Zachary Turner <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> 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/397cbd7d/attachment.html>