How does the debugger know exactly which Swift module your code came from? The upcoming Swift 6.4 release makes it more precise than ever, tracking the module path in debug info instead of looking it up by name, for faster and more reliable debugging. swift.org/blog/module-tr…
Sep 11, 2026 · 7:27 PM UTC
4
30
232
14,202
@SwiftLang Tracking the path also matters when separate build products reuse the same module name. A name lookup can be ambiguous. The recorded path tells the debugger which module actually produced the code.
0
0
0
291
@SwiftLang Swift’s move from module names to recorded paths made me wonder: which lookup problems does that fix, and what does the debugger still need to evaluate an expression? I asked an agent to diagram the change in a SmallDoc: smalldocs.org/s/hEjvoCfK9HEJ…
0
0
0
1
@SwiftLang The distinction in the article between inspecting a variable and evaluating a computed property is really helpful. It explains why one debugger command can work while the next suddenly needs the compiler and its modules.
0
0
0
49
@SwiftLang Module names are identifiers; module paths are provenance.
The useful test is whether the debugger can evaluate an expression correctly after two dependencies export the same module name. If it cannot, debug info lost an ownership boundary—not just a lookup optimization.
The useful test is whether the debugger can evaluate an expression correctly after two dependencies export the same module name. If it cannot, debug info lost an ownership boundary—not just a lookup optimization.
0
0
0
300