[lldb] Resolve Swift-implemented Objective-C classes using Swift runtime #10548
Conversation
|
@swift-ci test |
|
@swift-ci test |
|
This is now ready to review. |
|
@swift-ci test |
| dynamic_type.GetTypeSystem().dyn_cast_or_null<TypeSystemSwift>(); | ||
| if (ts && | ||
| ts->IsImportedType(dynamic_type.GetOpaqueQualType(), nullptr)) | ||
| type_name = static_type.GetDisplayTypeName(); |
There was a problem hiding this comment.
Do we always want to use the static type if the dynamic type is an Objective-C type? I guess in the REPL this makes sense
There was a problem hiding this comment.
Right, this is a very blunt tool to hide some of the Foundation implementation detail types that users are not meant to see / know / care about.
It doesn't not work for Swift-implemented types like _SwiftDeferredNSDictionary, which is going to be more prevalent going forward.
| auto tss = class_type.GetTypeSystem().dyn_cast_or_null<TypeSystemSwift>(); | ||
| if (!tss) { | ||
| is_clang_type = true; | ||
| if (auto module_sp = in_value.GetModule()) { |
There was a problem hiding this comment.
I don't understand why this is needed. If the type does not have a Swift type system (even if it's a swiftified objc type), then something has gone wrong, and we shouldn't be asking the Swift Language Runtime, no?
There was a problem hiding this comment.
Good question! Let me try replacing this with an assert(false) to answer how we get here.
There was a problem hiding this comment.
The answer is
bool ValueObjectDynamicValue::UpdateValue() {
...
#ifdef LLDB_ENABLE_SWIFT
// An Objective-C object inside a Swift frame.
if (known_type == eLanguageTypeObjC)
if ((exe_ctx.GetFramePtr() && exe_ctx.GetFramePtr()->GetLanguage().name ==
llvm::dwarf::DW_LNAME_Swift) ||
(exe_ctx.GetTargetPtr() && exe_ctx.GetTargetPtr()->IsSwiftREPL())) {
runtime = process->GetLanguageRuntime(lldb::eLanguageTypeSwift);
if (runtime)
found_dynamic_type = runtime->GetDynamicTypeAndAddress(
*m_parent, m_use_dynamic, class_type_or_name, dynamic_address,
value_type, local_buffer);
}
#endif // LLDB_ENABLE_SWIFT
let me see if I can simplify this.
There was a problem hiding this comment.
I was able to eliminate the entire resolve_objc lambda. The interesting part is that it was also trying to solve the private implementation detail problem, however, this was no longer working.
There was a problem hiding this comment.
Now that the resolve_objc lambda has been removed do we still need this block of code in case the type is a clang type then?
There was a problem hiding this comment.
Yes, this is still an actively used code block. I updated the comment to explain why.
|
@swift-ci test |
| auto tss = class_type.GetTypeSystem().dyn_cast_or_null<TypeSystemSwift>(); | ||
| if (!tss) { | ||
| is_clang_type = true; | ||
| if (auto module_sp = in_value.GetModule()) { |
There was a problem hiding this comment.
Now that the resolve_objc lambda has been removed do we still need this block of code in case the type is a clang type then?
if the Objective-C runtime fails. If an Objective-C class is lazy, the Objective-C runtie may not have materialized class metadata for it. However, if the class is actually implemented in Swift, we can still resolve it using the Swift runtime. We should probably also add the same logic to the Objective-C runtime, but I don't want risk adding an inifinite recursion at this point in the release. rdar://145253225
|
@swift-ci test |
|
@augusto2112 I looked at where the Clang types come from, to see if we could avoid checking for Clang types in the SwiftLanguageRuntime. They are children of NSArray implementation objects, and are created by the matching Objective-C NSArray synthetic child provider. The Swift Array formatters forward to the ObjC formatters if the implementation is an Objective-C one, and they create Clang types. That's how situation is possible. |
|
@swift-ci test windows |
3 participants
if the Objective-C runtime fails. If an Objective-C class is lazy, the
Objective-C runtie may not have materialized class metadata for
it. However, if the class is actually implemented in Swift, we can
still resolve it using the Swift runtime. We should probably also add
the same logic to the Objective-C runtime, but I don't want risk
adding an inifinite recursion at this point in the release.