Open Radar

 
Summary:
If a Swift module is introduced dynamically to an executable at runtime, the corresponding Swift code in the module is not imported into lldb until and unless a breakpoint is set in the module itself and expressions parsed that cause the module to be imported.

I ran into this while converting some Objective-C based debugging helpers, categories on Cocoa classes, to Swift. Simply loading the bundle is enough to get the imported category methods to be available from lldb expressions from then on out. However, Swift-based class extension methods are not available unless explicitly imported in lldb or caused to be implicitly imported.

The attached sample project presents a concise example that can hopefully be used to refine this functionality.

Steps to Reproduce:
1. Open attached SwiftExtensionTest.zip
2. Set a breakpoint in applicationDidFinishLaunching in AppDelegate.swift, on the NSLog line.
3. Build and run the project.
4. When you break at the NSLog line, open the debugger console and type:

po myView.vh()


Expected Results:
The vh method is defined as a class extension on NSView in the dynamically loaded DebuggingBundle.bundle. Evaluating Swift expressions that rely upon modules that were dynamically loaded should work without jumping through extra hoops.


Actual Results:
An error is emitted: "error: value of type 'NSView' has no member 'vh'"

Version:
Version 7.3 (7D175)

Notes:
Whatever implicit module importing lldb is doing, it's enough to break in the module in question and force it to evaluate an expression relying upon the module's own code. From this point onward the evaluation will work as expected:

1. Set a breakpoint in ViewDebuggingHelpers.swift, at the super.initialize line.
2. Type po myView.vh() in the debugger console

From this point onward the module is imported into lldb and works as expected.


Configuration:


Attachments:
'SwiftExtensionTest.zip' was successfully uploaded.