@swift-ci create

Comment by Jim Ingham (JIRA)

The problem seems to be conforming to NSObjectProtocol (which UIViewControllerTransitioningDelegate conforms to). You can repro the bug using just NSObjectProtocol.

Not everything is broken, "po self" works and if you add locals expression evaluation with them in the extension function works. But it looks like when you make an NSObject derived class (which already conforms to NSObjectProtocol) also conform to NSObjectProtocol by another path, we lost the NSObject-ness of the class. For instance if you do "frame var self" you won't see any of the ivars for UIViewController. Since we don't know about those ivars, we're not going to print or access the ones on the Swift side correctly.

Comment by Jovan (JIRA)

jingham@apple.com (JIRA User) sorry I meant everything regarding the protocol itself. So maybe you could adjust the bug to be more precise, but the issue is that the debugger is rendered pretty much completely useless since you can't use p/po {any var that protocol guarantees is there} nor e { any method that protocol guarantees is there }. The variables view is also acting as if all the variables are not yet initialized. I also haven't found a reasonable workaround, the best so far is to go a step back in the stack and print that same variable from another context.

OK, this looks like a type reconstruction bug (thanks to Jim for triaging!), so it's something I'll look at.

Comment by Jim Ingham (JIRA)

Milenkovic (JIRA User) I wasn't criticizing the bug, your reproducer was easy to use, so you did you job correctly. I wasn't trying to minimize the effects, just trying to be precise about what they were. Sorry if I gave the wrong impression.

For context: since self in this extension method is only known as "an entity conforming to a protocol", it doesn't have a statically known type, and going just by the debug information we would have no way to access its actual fields. So we have to reconstruct the actual type with all the ivars the protocol knows nothing about from the runtime. That turns out to be one of the trickier parts of the swift debugger. The fact that it is the ivars of the reconstructed type that are wrong, and not other aspects of the context we're stopped in, tells us that this is a type reconstruction bug, (and allows me to palm it off on Davide 😉)

Comment by Jovan (JIRA)

jingham@apple.com (JIRA User) no no I didn't get that impression, my intention was simply to point out that you should feel free to adjust the bug to be better with the info you got from your debugging to make the job easier for the assignee. I basically knew right away that I didn't provide the minimal bug because I don't know about the debugger and objc runtime so didn't have that much time to waste on it, so any improvement would be welcome. I also prefer tickets assigned to me to have this info up there where it belongs instead of in the comments, so it's also personal preference 👍

Fixed on master.

Issues should go to "Resolved" when they're fixed; only the originator should close them!