Skip to content
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

Open
mattneub opened this issue Oct 9, 2019 · 6 comments
Open

[SR-11593] REPL incorrectly reports URL as nil #4477

mattneub opened this issue Oct 9, 2019 · 6 comments
Labels
bug Something isn't working LLDB for Swift

Comments

@mattneub
Copy link

mattneub commented Oct 9, 2019

Previous ID SR-11593
Radar None
Original Reporter @mattneub
Type Bug
Additional Detail from JIRA
Votes 16
Component/s LLDB for Swift
Labels Bug
Assignee jingham@apple.com (JIRA)
Priority Medium

md5: 52c0d59c4f387bd8ac5d0f53094bdb03

is blocked by:

  • SR-11546 LLDB gets Swift Foundation overlay optionals wrong

duplicates:

  • SR-13103 lldb cannot evaluate optional date objects

is duplicated by:

  • SR-12444 Xcode Debugger and lldb fail to display Foundation Types
  • SR-13446 Optional.none != nil

relates to:

  • SR-4091 Incorrect result shown in REPL for 'UInt8?'
  • SR-11546 LLDB gets Swift Foundation overlay optionals wrong

Issue Description:

Here's a curious little conversation with the command line that came up on Stack Overflow lately:

themini:~ mattneubelcap$ swift
Welcome to Apple Swift version 5.1 (swiftlang-1100.0.270.13 clang-1100.0.33.7).
Type :help for assistance.
  1> import Foundation
  2> let url = URL(string:"https://bugs.swift.org")
url: URL? = nil
  3> print(url)
Optional(https://bugs.swift.org)
  4> url == nil
$R0: Bool = false
  5> url
$R1: URL? = nil

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).

@belkadan
Copy link

belkadan commented Oct 9, 2019

Indeed, very possibly the same.

@swift-ci
Copy link

swift-ci commented Nov 9, 2020

Comment by Dave (JIRA)

Is there any plan to fix this? It renders the debugger practically useless.

@kastiglione
Copy link

MacDavePro (JIRA User) for the debugger, a workaround is to use `po`

@swift-ci
Copy link

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.

@swift-ci
Copy link

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!

@swift-ci
Copy link

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.

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
@shahmishal shahmishal transferred this issue from apple/swift May 7, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working LLDB for Swift
Projects
None yet
Development

No branches or pull requests

4 participants