Skip to content

Commit 7e8ae7b

Browse files
committed
[lldb][swift] Use dynamic types as a fallback in AddVariableInfo
Since commit eaceb46 AddVariableInfo is always using the dynamic type if requested. The dynamic types appear to not always be usable and caused a few tests to fail(1), but as the swiftTest decorator was always skipping all Swift tests since commit 2c911bc this wasn't discovered before landing. This patch restores the old behaviour where possible by first trying the non-dynamic type and falling back to the dynamic type in case the non-dynamic type can't be fully realized. (1) All the failures seem to be related to us reading corrupt data from memory when using the dynamic type in the expression parser. The dynamic types itself appear to be perfectly fine, so it's not clear why the new behaviour doesn't work.
1 parent bcffc98 commit 7e8ae7b

File tree

5 files changed

+38
-31
lines changed

5 files changed

+38
-31
lines changed

lldb/source/Plugins/ExpressionParser/Swift/SwiftExpressionParser.cpp

+35-20
Original file line numberDiff line numberDiff line change
@@ -576,6 +576,22 @@ static void AddRequiredAliases(Block *block, lldb::StackFrameSP &stack_frame_sp,
576576
}
577577
}
578578

579+
/// Returns the Swift type for a ValueObject representing a variable.
580+
/// An invalid CompilerType is returned on error.
581+
static CompilerType GetSwiftTypeForVariableValueObject(
582+
lldb::ValueObjectSP valobj_sp, lldb::StackFrameSP &stack_frame_sp,
583+
SwiftLanguageRuntime *runtime, bool use_dynamic_value) {
584+
// Check that the passed ValueObject is valid.
585+
if (!valobj_sp || valobj_sp->GetError().Fail())
586+
return CompilerType();
587+
CompilerType result = valobj_sp->GetCompilerType();
588+
if (use_dynamic_value)
589+
result = runtime->BindGenericTypeParameters(*stack_frame_sp, result);
590+
if (!result.GetTypeSystem()->SupportsLanguage(lldb::eLanguageTypeSwift))
591+
return CompilerType();
592+
return result;
593+
}
594+
579595
/// Create a \c VariableInfo record for \c variable if there isn't
580596
/// already shadowing inner declaration in \c processed_variables.
581597
static llvm::Optional<llvm::Error> AddVariableInfo(
@@ -602,31 +618,30 @@ static llvm::Optional<llvm::Error> AddVariableInfo(
602618
if (processed_variables.count(overridden_name))
603619
return {};
604620

605-
CompilerType var_type;
606-
if (stack_frame_sp) {
607-
lldb::ValueObjectSP valobj_sp =
608-
stack_frame_sp->GetValueObjectForFrameVariable(variable_sp,
609-
use_dynamic);
621+
if (!stack_frame_sp)
622+
return llvm::None;
610623

611-
if (!valobj_sp || valobj_sp->GetError().Fail()) {
612-
// Ignore the variable if we couldn't find its corresponding
613-
// value object. TODO if the expression tries to use an
614-
// ignored variable, produce a sensible error.
615-
return {};
616-
}
617-
var_type = valobj_sp->GetCompilerType();
618-
if (use_dynamic > lldb::eNoDynamicValues) {
619-
if (auto *stack_frame = stack_frame_sp.get())
620-
var_type =
621-
runtime->BindGenericTypeParameters(*stack_frame, var_type);
622-
}
623-
}
624+
lldb::ValueObjectSP valobj_sp =
625+
stack_frame_sp->GetValueObjectForFrameVariable(variable_sp,
626+
lldb::eNoDynamicValues);
627+
628+
const bool use_dynamic_value = use_dynamic > lldb::eNoDynamicValues;
629+
630+
CompilerType var_type = GetSwiftTypeForVariableValueObject(
631+
valobj_sp, stack_frame_sp, runtime, use_dynamic_value);
624632

625633
if (!var_type.IsValid())
626634
return {};
627635

628-
if (!var_type.GetTypeSystem()->SupportsLanguage(lldb::eLanguageTypeSwift))
629-
return {};
636+
// If the type can't be realized and dynamic types are allowed, fall back to
637+
// the dynamic type.
638+
if (!SwiftASTContext::IsFullyRealized(var_type) && use_dynamic_value) {
639+
var_type = GetSwiftTypeForVariableValueObject(
640+
valobj_sp->GetDynamicValue(use_dynamic), stack_frame_sp, runtime,
641+
use_dynamic_value);
642+
if (!var_type.IsValid())
643+
return {};
644+
}
630645

631646
Status error;
632647
CompilerType target_type = ast_context.ImportType(var_type, error);
Original file line numberDiff line numberDiff line change
@@ -1,6 +1,4 @@
11
import lldbsuite.test.lldbinline as lldbinline
22
from lldbsuite.test.decorators import *
33

4-
lldbinline.MakeInlineTest(__file__, globals(), decorators=[swiftTest,
5-
expectedFailureAll #FIXME: This regressed silently due to 2c911bceb06ed376801251bdfd992905a66f276c
6-
])
4+
lldbinline.MakeInlineTest(__file__, globals(), decorators=[swiftTest])
Original file line numberDiff line numberDiff line change
@@ -1,6 +1,4 @@
11
import lldbsuite.test.lldbinline as lldbinline
22
from lldbsuite.test.decorators import *
33

4-
lldbinline.MakeInlineTest(__file__, globals(), decorators=[swiftTest,
5-
expectedFailureAll #FIXME: This regressed silently due to 2c911bceb06ed376801251bdfd992905a66f276c
6-
])
4+
lldbinline.MakeInlineTest(__file__, globals(), decorators=[swiftTest])

lldb/test/API/lang/swift/unknown_self/TestSwiftUnknownSelf.py

-1
Original file line numberDiff line numberDiff line change
@@ -33,7 +33,6 @@ def check_class(self, var_self, broken):
3333
self.expect("fr v self", substrs=["hello", "world"])
3434

3535

36-
@skipIf #FIXME: This regressed silently due to 2c911bceb06ed376801251bdfd992905a66f276c
3736
@skipIf(bugnumber="SR-10216", archs=['ppc64le'])
3837
@swiftTest
3938
def test_unknown_self_objc_ref(self):

lldb/test/API/lang/swift/variables/error_type/TestSwiftErrorType.py

+1-4
Original file line numberDiff line numberDiff line change
@@ -12,7 +12,4 @@
1212
import lldbsuite.test.lldbinline as lldbinline
1313
from lldbsuite.test.decorators import *
1414

15-
lldbinline.MakeInlineTest(__file__, globals(), decorators=[
16-
#FIXME: This regressed silently due to 2c911bceb06ed376801251bdfd992905a66f276c
17-
expectedFailureAll,
18-
swiftTest])
15+
lldbinline.MakeInlineTest(__file__, globals(), decorators=[swiftTest])

0 commit comments

Comments
 (0)