As a developer of a third-party library, I want to provide the best possible debugging experience. But, the rub: the primary type I seek to improve working with involves a) an opaque structure and b) user-provided closures. Swift-native
Mirror types provide a great solution to overcoming the first problem, but that's then invalidated by any attempt to solve the second problem; Swift function types all
Luckily, I see that once
p gets ahold of a function reference, LLDB puts a ton of work into recovering a good display name even in the face of reabstractions (which is really cool!). But the fine difference between
po is likely to mystify some. Worse,
p can't see into my opaque type without lots of work…
I've delved into Swift's patches atop LLDB, and found its various and sundry implementations of Data Formatter types. Going down this road seems promising, but has produced a few questions I don't have great answers to.
- Are there reasons why Swift's synthetic children providers don't talk to
Mirrorand instead dump all of that representation to a string in-process?
- Is messing with custom providers a good idea for me as a third party to invest in? Just looking at what swift-lldb's providers are doing, a lot of things I intend to write go beyond simple method calls and would end up coupling to the ABI representation somehow (f.ex. having to work around SR-7565). My debugging aids could be more frustrating than helpful if they break suddenly!
- If synthetic children are The Right Way™️ of doing this (at least for the near future), what should I be doing to make mine resilient to or at least of aware of the ABI representation?