Currently with Swift 6.3, unless you pass --features=swift.use_explicit_swift_module_map, Swift doesn't record the path to transitive swiftmodule dependencies in your output swiftmodule. For example:
swift_library(
name = "lib",
srcs = ["lib.swift"],
module_name = "lib",
)
swift_binary(
name = "bin",
srcs = ["bin.swift"],
deps = [":lib"],
)
$ llvm-bcanalyzer --dump bazel-out/darwin_arm64-dbg/bin/examples/examples_bin.swiftmodule | grep IMPORTED_MODULE
<IMPORTED_MODULE abbrevid=4 op0=0 op1=0 op2=0 op3=0/> blob data = 'Swift'
<IMPORTED_MODULE abbrevid=4 op0=0 op1=0 op2=0 op3=0/> blob data = 'SwiftOnoneSupport'
<IMPORTED_MODULE abbrevid=4 op0=0 op1=0 op2=0 op3=0/> blob data = 'Testing'
<IMPORTED_MODULE abbrevid=4 op0=0 op1=0 op2=0 op3=0/> blob data = '_Concurrency'
<IMPORTED_MODULE abbrevid=4 op0=0 op1=0 op2=0 op3=0/> blob data = '_StringProcessing'
<IMPORTED_MODULE abbrevid=4 op0=0 op1=0 op2=0 op3=0/> blob data = '_SwiftConcurrencyShims'
<IMPORTED_MODULE abbrevid=4 op0=0 op1=0 op2=0 op3=0/> blob data = 'lib'
This potentially matters for debugging. First party dependencies, like my lib in this example, get added to the final binary with -add_ast_path, so those aren't a problem:
$ dsymutil -s bazel-bin/examples/bin | grep AST
[ 20] 000006a7 32 (N_AST ) 00 0000 0000000000000000 'bazel-out/darwin_arm64-dbg/bin/examples/lib.swiftmodule'
[ 21] 000006df 32 (N_AST ) 00 0000 0000000000000000 'bazel-out/darwin_arm64-dbg/bin/examples/examples_bin.swiftmodule'
But for dependencies like Testing here, which is a swiftmodule that was built from a swiftinterface in the SDK (vs Swift and some of the other modules which are provided as prebuilt swiftmodule files), it's possible lldb cannot find this swiftmodule and that degrades debugging. It looks to me like it will still find the prebuilt swiftmodule file ones, so we don't have to worry about those.
When you pass --features=swift.use_explicit_swift_module_map, the relative paths from the explicit module json file are also stored here:
$ llvm-bcanalyzer --dump bazel-out/darwin_arm64-dbg/bin/examples/examples_bin.swiftmodule | grep IMPORTED_MODULE
<IMPORTED_MODULE abbrevid=4 op0=0 op1=0 op2=0 op3=1/> blob data = 'Swift'
<IMPORTED_MODULE_PATH abbrevid=6/> blob data = '__bazel_developer_dir_26_4_1_17E202/Toolchains/XcodeDefault.xctoolchain/usr/lib/swift/macosx/prebuilt-modules/26.4/Swift.swiftmodule/arm64e-apple-macos.swiftmodule'
<IMPORTED_MODULE abbrevid=4 op0=0 op1=0 op2=0 op3=1/> blob data = 'SwiftOnoneSupport'
<IMPORTED_MODULE_PATH abbrevid=6/> blob data = '__bazel_developer_dir_26_4_1_17E202/Toolchains/XcodeDefault.xctoolchain/usr/lib/swift/macosx/prebuilt-modules/26.4/SwiftOnoneSupport.swiftmodule/arm64e-apple-macos.swiftmodule'
<IMPORTED_MODULE abbrevid=4 op0=0 op1=0 op2=0 op3=1/> blob data = 'Testing'
<IMPORTED_MODULE_PATH abbrevid=6/> blob data = 'bazel-out/darwin_arm64-dbg-ST-52388a551d5e/bin/external/+system_sdk+system_sdk_xcode_26_4_1_17E202/MacOSX_Testing_outs/Testing.swiftmodule'
<IMPORTED_MODULE abbrevid=4 op0=0 op1=0 op2=0 op3=1/> blob data = '_Concurrency'
<IMPORTED_MODULE_PATH abbrevid=6/> blob data = '__bazel_developer_dir_26_4_1_17E202/Toolchains/XcodeDefault.xctoolchain/usr/lib/swift/macosx/prebuilt-modules/26.4/_Concurrency.swiftmodule/arm64e-apple-macos.swiftmodule'
<IMPORTED_MODULE abbrevid=4 op0=0 op1=0 op2=0 op3=1/> blob data = '_StringProcessing'
<IMPORTED_MODULE_PATH abbrevid=6/> blob data = '__bazel_developer_dir_26_4_1_17E202/Toolchains/XcodeDefault.xctoolchain/usr/lib/swift/macosx/prebuilt-modules/26.4/_StringProcessing.swiftmodule/arm64e-apple-macos.swiftmodule'
<IMPORTED_MODULE abbrevid=4 op0=0 op1=0 op2=0 op3=0/> blob data = '_SwiftConcurrencyShims'
<IMPORTED_MODULE abbrevid=4 op0=0 op1=0 op2=0 op3=1/> blob data = 'lib'
<IMPORTED_MODULE_PATH abbrevid=6/> blob data = 'bazel-out/darwin_arm64-dbg/bin/examples/lib.swiftmodule'
Currently these paths would have to be remapped separately, but we might be able to change __bazel_developer_dir_26_4_1_17E202 to PLACEHOLDER_DEVELOPER_DIR so that only one lldb mapping has to be added by the user.
Swift 6.4 will have this commit: swiftlang/swift@fa71d1d which makes it look like it will store the path to the explicit module json file itself, which will change things a bit. We'll have to test with that version to see how it works once an Xcode beta is available with it.
Currently with Swift 6.3, unless you pass
--features=swift.use_explicit_swift_module_map, Swift doesn't record the path to transitive swiftmodule dependencies in your output swiftmodule. For example:This potentially matters for debugging. First party dependencies, like my
libin this example, get added to the final binary with-add_ast_path, so those aren't a problem:But for dependencies like
Testinghere, which is a swiftmodule that was built from a swiftinterface in the SDK (vs Swift and some of the other modules which are provided as prebuilt swiftmodule files), it's possible lldb cannot find this swiftmodule and that degrades debugging. It looks to me like it will still find the prebuilt swiftmodule file ones, so we don't have to worry about those.When you pass
--features=swift.use_explicit_swift_module_map, the relative paths from the explicit module json file are also stored here:Currently these paths would have to be remapped separately, but we might be able to change
__bazel_developer_dir_26_4_1_17E202toPLACEHOLDER_DEVELOPER_DIRso that only one lldb mapping has to be added by the user.Swift 6.4 will have this commit: swiftlang/swift@fa71d1d which makes it look like it will store the path to the explicit module json file itself, which will change things a bit. We'll have to test with that version to see how it works once an Xcode beta is available with it.