When Swift came out, I kinda stopped using Xcode’s Step Into process control in Debug Bar, mostly due to Swift’s more frequent usage of accessors and computed properties etc.
But 2016’s WWDC talk Debugging Tips and Tricks https://developer.apple.com/videos/play/wwdc2016/417/ says that I shouldn’t abandon trying. I recommend you watching the whole video, or at least the last speaker, who talks about Step In problem among other things.
No time to watch? Just use sif nameOfFunction
, which let’s you specify WHERE you want to Step In, avoiding all the unneeded stuff.
To understand what sif does, let’s un-abbreviate it using help in lldb:
'sif' is an abbreviation for 'thread step-in -e block -t %1
Few new things appear here, let’s break them down, assuming that we know that thread step-in
is basically the Xcode’s Step Into.
-t %1
is the main thing to notice here. It stands for --step-in-target <function-name>
, and that’s where we pass what we are looking for, for example function name. It works with partial matches, it doesn’t have to be called with the full function name (as noted in this SO answer).
-e block
is important thing too. It stands for --end-linenumber
, and if we don’t specify it, it will only continue searching for our nameOfFunction until next line, which is not what we want in some cases, e.g. multiline function calls. We could’ve give it some other line, for example currentLine + 10, but we don’t need to, because there is helper argument block
, which will “step to the end of the current block” © help. I haven’t found what exactly “block” means, but it seems it’s basically “function”.