New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[SR-11593] REPL incorrectly reports URL as nil #4477
Comments
Indeed, very possibly the same. |
Comment by Dave (JIRA) Is there any plan to fix this? It renders the debugger practically useless. |
MacDavePro (JIRA User) for the debugger, a workaround is to use `po` |
Comment by Dave (JIRA) @kastiglione - Thanks Dave, thats what I have been doing. But it is excruciatingly tedious to step into the depths of an object graph, one field at a time, again for each line of code as you step through a stack of calls searching for the cause of a bug. Additionally, many other IDEs rely on LLDB for their own debug variable displays - eg AppCode and CLion. Using po there is slightly more irritating and defeats much of the value of debugging in an IDE. I am actually stunned this issue persists having been reported so long ago. I have put up with it for a while now, relying on unit tests to help avoid debugging production code issues. Are debugger users really so rare? I suspect one reason for the lack of attention may be that the more general issue has been marked as a duplicate of this specific case, possibly obscuring the breadth of the effect of this bug. |
Comment by Anthony Wharton (JIRA) I’ll echo Dave’s frustrations. My code base is affected by this as some of our core model objects include fields which break the debugger, and it seems to have the knock on effect of breaking any further objects that include these core components within them. This renders the debugger entirely unreliable for testing many elements in our codebase, as it’s difficult to keep track of which objects may be nil through the debugger breaking, and which may be nil as they are actually nil. Having these sorts of trust issues with the tooling leads to a very frustrating debugging experience - one I wouldn’t wish on anyone! I know echoing complaints is not productive and why there are voting mechanisms here, so I will add that I would happily offer assistance with this issue if that is possible, however my technical knowledge into the root cause is quite limited so that offer comes with the condition of requiring pointing in the right direction! |
Comment by Jim Ingham (JIRA) Note, there were two bugs here. One was that lldb didn't understand enum's that had a "resilient" type as one of the variants. The other is that the data formatter for Optional - which is an enum under the covers - wasn't doing correct error checking and mistook "error getting value" for "value is nil". I fixed the latter bug. With those changes you'll get an error about not being able to fetch the value in these cases, rather than an incorrect value, which is somewhat better. Getting the actual value is harder than it should be because the subsystem in Swift that lldb was using to grok swift Enums didn't support enums with resilient types as variants. Only the reflection API's know how to do that, so that whole bit of business needs to be rewritten to use reflection. |
Additional Detail from JIRA
md5: 52c0d59c4f387bd8ac5d0f53094bdb03
is blocked by:
duplicates:
is duplicated by:
relates to:
Issue Description:
Here's a curious little conversation with the command line that came up on Stack Overflow lately:
I have not tried to determine what other types behave this way, but I suspect is has to do with the Foundation overlay. This is interesting, if so, because I recently reported another bug involving LLDB incorrectly reporting nil for Optional Foundation overlay types (https://bugs.swift.org/browse/SR-11546).
The text was updated successfully, but these errors were encountered: