[all-commits] [llvm/llvm-project] 034eae: [lldb][DataFormatters] Adjust retrieval of unorder...

[Michael Buch via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 034eaeddc30cbaf273744580f15325514d5fb928
      https://github.com/llvm/llvm-project/commit/034eaeddc30cbaf273744580f15325514d5fb928
  Author: Michael Buch <michaelbuch12 at gmail.com>
  Date:   2025-05-20 (Tue, 20 May 2025)

  Changed paths:
    M lldb/source/Plugins/Language/CPlusPlus/LibCxxUnorderedMap.cpp

  Log Message:
  -----------
  [lldb][DataFormatters] Adjust retrieval of unordered_map element type (#140256)

A user ran into an issue where the libc++ `std::unordered_map` formatter
fails because it can't deduce the `element_type`. That happens because
the `node_type` is a forwad declaration. And, in fact, dsymutil stripped
the definition for `std::__1::__hash_node<...>` for a particular
instantiation. While I'm still unclear whether this is a dsymutil bug,
this patch works around said issue by getting the element type from the
`__table_` member.

Drive-by:
- Set the `m_element_type` in `Update`, which is where the other members
are initialized

I don't have a reduced example of this unfortunately. But the crux of
the issue is that `std::__1::__hash_node<...>` only has a forward
declaration in the dsym. Then trying to call `GetTypeTemplateArgument`
on that `CompilerType` fails. And even if the definition was present in
the dsym it seems like we're stopped in a context where the CU only had
a forward declaration DIE for that type and the `node_type` never ends
up being completed with the definition that lives in another CU.

rdar://150813798



To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications