[Debug] Add pointer based stringForPrintObject #84742
Conversation
Adds an overload of `stringForPrintObject` which takes a pointer and mangled typename as arguments. This will be used to improve performance and resilience of `po` in lldb. The pointer and mangled typename are used to construct an `Any` value, which is then passed into the primary implementation of `stringForPrintObject`. This allows calling `stringForPrintObject` without having to first construct a context that contains all necessary Swift modules. This will improve speed, and also resilience when modules cannot be loaded for whatever reason.
kastiglione requested review from mikeash, lorentey, adrian-prantl and augusto2112 
| return target | ||
| } | ||
| | ||
| public static func stringForPrintObject(_ pointer: UnsafeRawPointer?, mangledTypeName: String) -> String { |
There was a problem hiding this comment.
I intend to rework this signature, either making it throws, or changing the return type to Result or Optional.
| return "invalid type \(mangledTypeName)" | ||
| } | ||
| | ||
| func loadPointer<T>(type: T.Type) -> Any { |
There was a problem hiding this comment.
I'm not sure what would happen here if T is noncopyable. Presumably it would be OK not to support noncopyable types as a first implementation, but we should make sure they at least do something vaguely sensible when failing. I don't think we can use reflection on them at all, but we could potentially check for noncopyable types and return the demangled type name and some message about not being able to show the contents.
There was a problem hiding this comment.
po today doesn't work at all for noncopyable types, so this won't by any worse.
| unsafe _getTypeByMangledNameInContext( | ||
| mangledTypeName, | ||
| UInt(mangledTypeName.count), | ||
| genericContext: nil, |
There was a problem hiding this comment.
Since we're passing nil here, does it mean this doesn't work with generic types the moment?
There was a problem hiding this comment.
It will work with generic types as long as the mangled name is fully bound, i.e. there aren't any "get the 3rd type parameter from the type I'm in" directives. It may not work for generic types that depend on the context (e.g. you have a [T] local variable), depending on how this mangled name is obtained. But as long as you can get a name with all the parts in it, it will work.
There was a problem hiding this comment.
as Mike says, this depends on lldb being able to construct a concrete mangled type name. @augusto2112 you've dealt the most with generic types within expression evaluation, are there known cases where this will be a problem?
Adds an overload of
_DebuggerSupport.stringForPrintObjectwhich takes a pointer and mangled typename as arguments. This will be used to improve performance and resilience ofpoin lldb.The pointer and mangled typename are used to construct an
Anyvalue, which is then passed into the primary implementation ofstringForPrintObject.This allows calling
stringForPrintObjectwithout having to first construct a context that contains all necessary Swift modules. This will improve speed, and also resilience when modules cannot be loaded for whatever reason.rdar://158968103