diff options
author | Michael Buch <michaelbuch12@gmail.com> | 2025-05-20 09:44:26 +0100 |
---|---|---|
committer | GitHub <noreply@github.com> | 2025-05-20 09:44:26 +0100 |
commit | 034eaeddc30cbaf273744580f15325514d5fb928 (patch) | |
tree | 38e8742a3e700b9057eabb964747c73d16a9410f /clang/lib/CodeGen/CodeGenFunction.cpp | |
parent | 32a1b6a70b3ec9066dd70ccf538f735a5c58e031 (diff) | |
download | llvm-034eaeddc30cbaf273744580f15325514d5fb928.zip llvm-034eaeddc30cbaf273744580f15325514d5fb928.tar.gz llvm-034eaeddc30cbaf273744580f15325514d5fb928.tar.bz2 |
[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
Diffstat (limited to 'clang/lib/CodeGen/CodeGenFunction.cpp')
0 files changed, 0 insertions, 0 deletions