aboutsummaryrefslogtreecommitdiff
path: root/llvm/lib/Transforms/Utils/ValueMapper.cpp
diff options
context:
space:
mode:
authorFelipe de Azevedo Piovezan <fpiovezan@apple.com>2023-06-20 12:21:38 -0400
committerFelipe de Azevedo Piovezan <fpiovezan@apple.com>2023-06-28 09:19:14 -0400
commite12c701ff0405880045f0330fb6ff94e31ec5c47 (patch)
treea37aa8c94632ae6c686c69008196d734ef772578 /llvm/lib/Transforms/Utils/ValueMapper.cpp
parent98390ccb80569e8fbb20e6c996b4b8cff87fbec6 (diff)
downloadllvm-e12c701ff0405880045f0330fb6ff94e31ec5c47.zip
llvm-e12c701ff0405880045f0330fb6ff94e31ec5c47.tar.gz
llvm-e12c701ff0405880045f0330fb6ff94e31ec5c47.tar.bz2
[lldb] Use LLVM's implementation of AppleTables for apple_debug_types
This commit is replacing really old LLDB code, and we've found some odd behavior while doing this replacement. While the changes here are largely NFC, there are some subtle changes that fix such odd behavior. The most curious example of this is the method `FindCompleteObjCClassName`, which has a flag `must_be_implementation`. This flag was _only_ being respected for accelerator tables containing the atom `type_flags`, which seems counter-intuitive. The implementation for DWARF 5 tables does not do that and neither does the code introduced in this patch. There were other weird cases, for example, we found boolean logic that was always true in a code path: look for a `if !has_qualified_name...` deleted line; that condition was true by simple if/else analysis. Differential Revision: https://reviews.llvm.org/D153867
Diffstat (limited to 'llvm/lib/Transforms/Utils/ValueMapper.cpp')
0 files changed, 0 insertions, 0 deletions