aboutsummaryrefslogtreecommitdiff
path: root/lldb/source/Commands/CommandObjectProcess.cpp
diff options
context:
space:
mode:
authorPavel Labath <pavel@labath.sk>2025-05-02 14:20:14 +0200
committerGitHub <noreply@github.com>2025-05-02 14:20:14 +0200
commit26a1366380796f95f308faab5010b019c4b75b10 (patch)
treecb897639578aa5a07e69a1830467c450b3d14ee7 /lldb/source/Commands/CommandObjectProcess.cpp
parent41035f4aa8139353a532509e5d4406dbb07446ac (diff)
downloadllvm-26a1366380796f95f308faab5010b019c4b75b10.zip
llvm-26a1366380796f95f308faab5010b019c4b75b10.tar.gz
llvm-26a1366380796f95f308faab5010b019c4b75b10.tar.bz2
[lldb] Fix dynamic type resolution for types parsed from declarations (#137974)
This fixes a regression caused by us starting to parse types from declarations. The code in TypeSystemClang was assuming that the value held in ClangASTMetadata was authoritative, but this isn't (and cannot) be the case when the type is parsed from a forward-declaration. For the fix, I add a new "don't know" state to ClangASTMetadata, and make sure DWARFASTParserClang sets it only when it encounters a forward declaration. In this case, the type system will fall back to completing the type. This does mean that we will be completing more types than before, but I'm hoping this will offset by the fact that we don't search for definition DIEs eagerly. In particular, I don't expect it to make a difference in -fstandalone-debug scenarios, since types will nearly always be present as definitions. To avoid this cost, we'd need to create some sort of a back channel to query the DWARFASTParser about the dynamicness of the type without actually completing it. I'd like to avoid that if it is not necessary.
Diffstat (limited to 'lldb/source/Commands/CommandObjectProcess.cpp')
0 files changed, 0 insertions, 0 deletions