Classes implemented in Swift can be exposed to ObjC. For those classes, the ObjC
metadata is incomplete (the types of the ivars are incomplete), but as one would expect
the Swift metadata is complete. In such cases, the Swift runtime should be consulted
first when determining the dynamic type of a value.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
lldb/source/Core/ValueObjectDynamicValue.cpp | ||
---|---|---|
10 | Is there a way we can avoid using a plugin in non-plugin code? |
lldb/source/Core/ValueObjectDynamicValue.cpp | ||
---|---|---|
118–122 | @bulbazord this is where it's used, to work with ClassDescriptor which is part of the ObjCLanguageRuntime. I don't think it would make sense to lift that into the generic LangaugeRuntime. What other courses might there be? |
lldb/source/Core/ValueObjectDynamicValue.cpp | ||
---|---|---|
152 | This is a bit of a layering violation. Could the ObjC language runtime perform this check in GetDynamicTypeAndAddress and dispatch to the Swift runtime there? If you do this, we need to ensure we can't get into an infinite loop between the runtimes. Alternatively, we could add a virtual GetPreferredLanguageRuntime() method to LanguageRuntime that we call here, maybe? | |
lldb/source/Plugins/LanguageRuntime/ObjC/ObjCLanguageRuntime.h | ||
90 | Can you add a Doxygen commen? |
Is there a way we can avoid using a plugin in non-plugin code?