[all-commits] [llvm/llvm-project] 4dfe21: [lldb][DWARFASTParserClang] Added a check for the ...

[Timur Golubovich via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 4dfe212dade71e0e4e5ea4609e403f5e523eeb74
      https://github.com/llvm/llvm-project/commit/4dfe212dade71e0e4e5ea4609e403f5e523eeb74
  Author: Timur Golubovich <timur.golubovich at syntacore.com>
  Date:   2025-10-29 (Wed, 29 Oct 2025)

  Changed paths:
    M lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
    M lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
    M lldb/unittests/SymbolFile/DWARF/CMakeLists.txt
    M lldb/unittests/SymbolFile/DWARF/DWARFASTParserClangTests.cpp
    A lldb/unittests/SymbolFile/DWARF/Inputs/DW_AT_spec_decl_exists-test.yaml

  Log Message:
  -----------
  [lldb][DWARFASTParserClang] Added a check for the specialization existence (#154123)

[lldb][DWARFASTParserClang] Added a check for the specialization
existence

While debugging an application with incorrect dwarf information, where
    DW_TAG_template_value_parameter was lost, I found that lldb does not
check that the corresponding specialization exists. As a result, at the
stage when ASTImporter works, the type is completed in such a way that
    it inherits from itself. And during the calculation of layout, an
infinite recursion occurs. To catch this error, I added a corresponding
check
at the stage of restoring the type from dwarf information. I also added
a
trivial assert in clang to check that the class does not inherit from
itself.



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