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?
to your account
Xcode Version 11.3.1 (11C505)
I ran this in the simulator but this also occurs on the device. I believe this bug has existed for several years.
The Xcode debugger fails to display some Foundation Types correctly
in the Variables Pane. lldb also fails to print these same types
correctly using 'frame v' and 'print' however it does correctly
print them using 'po'.
This is easily seen using the attached project. Set a breakpoint
on the print statement in the ViewController class and debug
the app. Once the breakpoint is hit some Foundation Types will
display correctly in the Variables Pane and will print correctly
using frame v and p. These include Data, NotificationName,
Notification and builtin types like Int, and Float. ClosedRange
also works as expected.
A number of other types fail to display correctly in the Varibles
Pane and also fail to print correctly with frame v and print. They do
print correctly with po. These include Date, TimeZone, URL, Calendar
DateComponents, IndexPath. I haven't tested every type so others
probably fail as well.
Optionals of these failing types always display as nil in the
Variables Pane and in lldb frame v even when they aren't nil.
All these types work as expected in a playground and the descriptions
displayed in a playground for these types is what I expect to see
in Xcode and in lldb.
I've attached the project, the playground, and a couple screenshots
of what this looks like in Xcode.
The text was updated successfully, but these errors were encountered:
Sorry, something went wrong.
See also https://bugs.swift.org/browse/SR-12724
Looks like duplicate of SR-11593
Comment by Dave (JIRA)
@poya - despite the chronology I would say SR-11593 is a specific case of this root cause issue. If you want to close one as a duplicate, I would closed SR-11593 so focus stays on the root cause.
No branches or pull requests